ORDOVA
Canon · Framework

On the layers
a session sees.

This document maps the ordered context of a single session and governs how its rules are weighed, declaring that the synthesis itself shall hold no authority above its sources.

source: canon/framework.md

Preamble

Within a single session the Hand stands upon ordered layers, each framing those beneath it, from the System that may not be overridden to the tools summoned on demand.

These Articles set down how those layers compose, how their rules differ in kind, and by what discipline parallel work and derived views are kept honest.


I
the layered order of context
ratified · amendable
Article

The layers of a session, ordered outside-in.

The operating context of a session shall be composed of ordered layers, each framing those beneath it.

Ten layers compose what the Hand sees within a single session. First the Anthropic system prompt, ever present, governing identity, tone, and safety, which no user shall override. Then the environment context, which anchors every relative reference to an absolute fact: the working directory, the platform, the day, the model, the shell.

Above these stand the authored instructions: the user-global mandates, the domain rule files, and the project conventions, all always loaded. Then the learned layer of auto-memory, read on demand, distinct from rules because it is corrected and validated, not authored. Above memory stand the Skills, the Agents, the Hooks executed by the harness and not by the Hand, and finally the Tool layer, some loaded eagerly and some deferred until summoned.

Each layer frames the ones beneath it. The System is the floor. The Hand stands upon it.

10 layers: system prompt → environment → user CLAUDE.md → rules/*.md → project CLAUDE.md → MEMORY.md → skills → agents → hooks → tools
II
rules differ in kind
ratified · amendable
Article

Rules differ in kind, and the difference governs.

No rule shall be weighed as though all rules were of one kind.

Rules are prescriptive, naming the mechanical act; procedural, naming the sequence; epistemic, naming how to weigh sources; behavioural, naming the default; and communicative, naming the shape of address. The kind of a rule determines how it binds and how it fails.

The epistemic rules are the most powerful and the most fragile. They are the least bounded, for they shape judgment on situations the rule never anticipated, yet they are the easiest to drift upon, because nothing fails loudly when a rollup is quietly treated as authoritative. Mechanical rules enforce themselves; epistemic rules drift unless paired with a concrete case of how they fired in practice.

kinds: prescriptive · procedural · epistemic · behavioural · communicative
III
the brief is a plan, not live state
ratified · amendable
Article

A phased plan shall be verified against the ground.

No phase brief written ahead of time shall be trusted over the state of the files on disk.

When a refactor is sequenced across phases, and each phase's brief was written before the earlier phases ran, the later briefs go stale as earlier phases move files to homes the brief did not anticipate. The brief is a plan, not live state.

Between sequential phase agents, the on-disk state of every file the brief names shall be checked against the latest origin/main, and the next agent's prompt rewritten to reflect the true reduced scope. The agent shall be told which files have moved and where, and shall be directed to trust the scaffold over the brief on any disagreement.

git ls-tree -r origin/main --name-only | grep per brief path; preamble: brief is STALE, trust scaffold over brief
IV
parallel writers, isolated checkouts
ratified · amendable
Article

Parallel writers shall not share one working tree.

No two parallel agents that write code shall be pointed at the same checkout, even when the files they touch are disjoint.

Each code-writing agent dispatched in parallel against one repository shall work in an isolated checkout: a fresh clone to a unique path, or a worktree on its own branch. The disjoint-files matrix is necessary but not sufficient, for Git serialises the working tree through a single shared lane.

The danger is structural, not a fault of conduct. One agent stashes a dirty tree to clear it, commingling its work with another's; later it judges that stash out of scope and drops it, and the other's uncommitted work is permanently lost. Both agents behave correctly given their briefs; the shared tree is the cause. Read-only investigators need no isolation; sequential single-agent work in the primary checkout is also safe. Both checks shall pass before parallelising: disjoint files, and isolated checkouts.

git worktree add OR fresh git clone per code-writing agent; read-only agents exempt; gate on (a) disjoint files AND (b) isolated checkouts
V
uncoordinated sessions on one ticket
ratified · amendable
Article

Concurrent sessions on one ticket shall coordinate.

No session shall progress a shared ticket in ignorance of another session already at work upon it.

Where two separate sessions, distinct in process and shell and prompt, both advance the same ticket without coordinating, the coordination gap is structural even when both read the state correctly at the start. The closing keyword in a pull request forms the formal sidebar link only if the issue is open at the moment of merge; if another session has closed it first, the link will not form, though the timeline mention still posts as a visible cross-reference.

Before entering a worktree on a non-trivial ticket, the assignees, comments, and state shall be read, and recent activity by another session surfaced to the user before parallel work begins. Decision-side and implementation-side work may proceed together, but only if the briefs match. Compatibility that is merely lucky shall not be mistaken for compatibility that is engineered.

gh issue view --json assignees,comments,state before EnterWorktree; auto-mention timeline comment suffices, escalate to sidebar link only if depended upon
VI
the charter is a derived view
ratified · amendable
Article

This document is itself a derived view.

This framework shall hold no authority above the canonical files from which it is drawn.

By its own rule, this document is a synthesis of the rule files, the memory index, the agents, and the hooks. It is a derived view, not a source of truth. Where it says one thing and the canonical files say another, the files shall be trusted and this document regenerated.

So the Canon binds itself by the same law it sets upon every rollup beneath it.

if framework says X and canonical files (rules, MEMORY.md, agents, hooks) say Y, trust the files and regenerate

Ratification

These Articles may be amended in the open, as a charter shows its revisions.

ordova · canon/framework.md · ratified

The cursor waits for the next hand.

© Async Digital Ltd