rentemester

Imported from mikkelkrogsholm/rentemester (AGENTS.md). Install upstream with npx skills add mikkelkrogsholm/rentemester. Copyright stays with the author.

Artefaktformat

Brug kun flade filer som projekt- og arbejdsleverancer. Opret ikke Excel-, Word- eller andre Office-filer (.xlsx, .xls, .docx, .doc), medmindre brugeren udtrykkeligt beder om det i den konkrete opgave. Brug i stedet fx Markdown, YAML, JSON, JSONL, CSV, HTML eller OKF. Tabulær viden bør som udgangspunkt være CSV/JSONL med en menneskelæselig Markdown- eller HTML-visning.

CLI-kontrakt for agenter

Før du kalder rentemester-CLI'en muterende, læs docs/cli-contract.md. Kort:

• Actor-politik: enhver muterende kommando kræver en actor — --actor <user:...|agent:...|system:...> (skal stå i config/policy.yaml), eller en USER/LOGNAME/RENTEMESTER_AGENT/OPENCLAW_AGENT miljøvariabel. Uden actor afvises kommandoen med actor required for mutations.
• Exit-koder: 0 = succes (ok:true); 2 = parse-/brugsfejl (forkert kald — ret flag/argumenter); 1 = forretnings-/ledger-afvisning (kaldet var korrekt, men resultatet er ok:false — læs errors[]).

Produktgrænse: generel motor, lokale virksomhedsdata

Rentemester er et generelt bogføringsprodukt, som bruges af flere virksomheder. Produktkode, schema, regler, importere, validering, rapporter og tests skal derfor være genanvendelige og må ikke indeholde særlogik for en bestemt virksomhed, et bestemt CVR-nummer, en konkret kontoplan eller et konkret beløb.

• Implementér generelle domænemodeller og konfigurerbare mekanismer. Eksempler er Dinero-import, moms-roll-forward, en effektivt dateret virksomhedsgraf, mellemregningsafstemning og konsolideringsregler.
• Hold konkrete selskabsnavne, CVR-numre, ejerandele, kontomappinger, bankkonti, saldi, bilag og lokale policyvalg i det enkelte workspace eller virksomhedens konfiguration — aldrig som defaults eller hardcoding i GitHub-koden.
• Tests for generel kode skal bruge syntetiske virksomheder og beløb og dække både positive og fail-closed scenarier. En reel virksomheds eksport kan være et lokalt acceptkorpus, men må ikke checkes ind eller blive en skjult forudsætning for produktlogikken.
• En generel importregel skal udlede sin beslutning af dokumenterede kildefelter og regnskabsmæssige invariants. Hvis en bestemt virksomheds data kræver mapping eller menneskelig vurdering, gemmes beslutningen lokalt med auditspor; kontrollen må ikke svækkes globalt.
• En virksomhedsgraf i produktet beskriver det generelle schema og de generelle operationer. Den konkrete graf-instans tilhører workspacet. Hver juridisk enhed beholder sin egen ledger; koncernrapportering ligger som et dokumenteret read-only lag med eksplicitte elimineringer.

graphify

This project has a knowledge graph at graphify-out/ with god nodes, community structure, and cross-file relationships.

When the user types /graphify, use the Graphify CLI before doing anything else.

Rules:

• For codebase questions, first run graphify query "<question>" when graphify-out/graph.json exists. Use graphify path "<A>" "<B>" for relationships and graphify explain "<concept>" for focused concepts. These return a scoped subgraph, usually much smaller than GRAPH_REPORT.md or raw grep output.
• Dirty graphify-out/ files are expected after hooks or incremental updates; dirty graph files are not a reason to skip graphify. Only skip graphify if the task is about stale or incorrect graph output, or the user explicitly says not to use it.
• If graphify-out/wiki/index.md exists, use it for broad navigation instead of raw source browsing.
• Read graphify-out/GRAPH_REPORT.md only for broad architecture review or when query/path/explain do not surface enough context.
• After modifying code, run graphify update . to keep the graph current (AST-only, no API cost).