@dall337/lore 0.0.0-stage → 0.1.0

package/suite/policies/memory.md

@@ -0,0 +1,453 @@
+# Memory Usage Policy
+
+Scoped agent-governance procedure (AGENTS.md §1/§2). Load on first contact
+with the repository and whenever configuring, reading, or writing its
+operational memory. Resolve the chosen entry point from AGENTS.md §5.
+
+## 0. Configured Memory
+
+> **Addendum (2026-10-02, owner-directed memory adaptation):** The bundled
+> web is an available backend. A project may instead point to existing
+> agent-native memory, a company memory system, or another approved
+> location. This section governs selection. Sections 1–7 describe the
+> bundled web; their layout, identity files, content rules, append-only
+> formatting, and git conventions apply when that backend is selected.
+
+> **Erratum (2026-10-02, owner clarification of the web):** The navigable
+> map and progressively specific rings in §§1–2 apply across storage
+> providers. The earlier qualification of §§1–7 makes their storage-specific
+> file layout, identity files, and mutation conventions conditional; it
+> does not make the web's navigation model optional.
+
+### Preserve the Navigable Rings
+
+Give agents a discoverable repository hub, then a route through categories
+that match the actual repository. The first ring names broad areas or
+concerns. Each deeper ring narrows to a subsystem, workflow, feature, or
+other working scope until the agent reaches the node that points to the
+relevant code, decisions, task evidence, and current status.
+
+For example, a route might be: repository hub → data storage → writes →
+retry behavior → the owning code and journal. The categories follow the
+repository; there is no universal taxonomy or prescribed number of rings.
+Create narrower nodes as the work and information require them, and add
+cross-links where another area matters to the current task.
+
+Keep navigation nodes small: scope, the next useful links, and concise
+status or pointers to status. Walk only the relevant branch and follow its
+references to authoritative detail. Avoid loading every ring or all stored
+memory to answer a question about one area. An agent that already knows
+the appropriate node can resume there and use parent or cross-links when
+the task broadens.
+
+This structure can live in the bundled files, a provider's categories and
+linked records, or another supported representation. If an existing
+agent/company memory cannot expose a usable walk, configure a thin
+navigation index elsewhere that points into that memory and the repository.
+The index supplies routes; the existing records retain their authority and
+content conventions. Record how the route maps to provider references or
+scoped queries in AGENTS.md §5 so another agent can follow it too.
+
+### Select the Existing Home First
+
+Before creating a memory directory or registry, read the memory
+configuration in [AGENTS.md §5](../AGENTS.md#memory-configuration), or the
+configuration document it points to. Inspect established project and
+company memory instructions. Use the selected system and its repository
+scope. If its entry point already exposes the repository web, an agent can
+orient there directly. Otherwise configure the navigation mapping or a
+thin index that leads to its records; a replacement memory module is
+unnecessary.
+
+When no choice has been made, help the owner record one. The choices are
+the bundled link web, an existing agent/company memory system, or another
+location such as a shared file, document, or service. Identify how agents
+find, read, and update the chosen home. Keep a discoverable pointer in
+AGENTS.md even when the memory itself lives elsewhere.
+
+An existing company's access, content, history, and retention conventions
+continue to govern its system. Do not replace them with the bundled web's
+folder layout or append-only file rules, migrate its records, or create a
+competing copy of its knowledge without an owner decision. A pointer index
+can provide the web's navigation while leaving those records in place.
+A later backend change is recorded in the configuration and the chosen
+decision record. The evolution process in §6 still applies, using the
+configured locations.
+
+### Keep the Repository Knowledge Findable
+
+For the repository's operational records, preserve the useful role of
+memory: find current status, the relevant artifacts, and enough dated
+context to distinguish a current decision from one it superseded. Use the
+provider's own representation for those records. Canonical code,
+documentation, and task evidence remain authoritative; memory should
+point to them and identify the status it records.
+
+An agent's memory may also hold other material under that agent's or
+company's conventions. LORE's link-web content rules describe the bundled
+module, not every record an existing provider maintains. Research detail
+continues to live in its task journal under [research policy](research.md),
+with a link or reference from the chosen memory when it supports one.
+
+### Match Coordination to Actual Visibility
+
+Check who can see the chosen records, whether they survive a session, and
+which agents can write them. Personal agent memory can aid its own
+orientation while a separate shared record handles claims and handoffs.
+Record that coordination location in AGENTS.md §5 and follow
+[orchestration policy §0](orchestration.md#0-configured-coordination).
+Do not assume a private memory, unsynced clone, or provider inaccessible to
+another agent is a shared coordination channel.
+
+When memory is unavailable or read-only, record that limit in the task
+journal and use a configured fallback when available. Continue authorized
+work that does not depend on unavailable knowledge or an unconfirmed
+claim. Do not silently manufacture another store and treat it as the
+configured source. Overlapping writes require a visible coordination
+record or explicit sequencing through the owner.
+
+### Coexist with Provider-Native Memory
+
+> **Addendum (2026-10-17, owner-directed provider memory):** Agent
+> harnesses keep memory of their own whether or not a project selects
+> it. This subsection governs coexistence. Owner rulings: the provider's
+> conventions win inside its store, except the shape of an index the
+> agent writes; LORE writes only pointers there; that index is a
+> links-only hub over areas named for the policies, reserved scopes
+> included; and the platform registry (§3) stays as coordination
+> identity.
+
+A harness's native memory, whether notes the agent writes for itself or
+memory the harness generates from past sessions, is that harness's
+**private layer**. It runs alongside the configured backend and becomes
+the backend only when the configuration selects it. Keeping it does not
+break the rule above against manufacturing another store; that rule
+covers a substitute treated as the configured source.
+
+**The provider's conventions govern inside its store.** Its record
+format, load limits, update and deletion rules, and its own judgment of
+what is worth keeping apply as the provider defines them. LORE adds one
+requirement where the agent writes the index: the hub shape below. The
+web's identity files (§3) and append-only discipline (§4) stop at the
+store's boundary.
+
+**Keep the layers separate.** The private layer holds what the provider
+keeps for the agent's own later use, such as the owner's working
+preferences and corrections. Anything another agent needs belongs in
+the shared layer: status, claims, releases, handoffs, decisions, and the
+routes to them live in the configured web, its coordination location, a
+task journal, or the repository. The shared layer never depends on a
+private memory for something another agent must know. When a private
+note turns out to matter beyond its harness, promote it: record it in
+the shared layer, or draft it as a rule through the accumulation loop
+(AGENTS.md §3).
+
+**LORE writes pointers, nothing more.** Where a provider lets the agent
+write its memory, the agent may record routes into LORE: the web entry
+point, a node it works from, a journal, the memory configuration. A
+pointer never restates, supersedes, or owns a repository or web record.
+When a pointer and its target disagree, the target is current and the
+pointer is corrected under the provider's rules. A pointer also follows
+the provider's guidance on what to save; a route the project's
+instruction files already give needs no second copy. Where the provider
+generates its memory itself, LORE writes nothing into it, and the
+instruction file the harness reads is the pointer channel. The hub and
+area indexes below are pointers of this kind.
+
+**The index is a hub, not a memory.** Providers load a capped index at
+session start; Claude Code, for one, reads the first 200 lines or 25KB
+of its `MEMORY.md`. Where the agent writes that index, it holds
+headings and links to area indexes, and nothing else: no prose, no
+status, no individual memories. Each area index holds headings, one
+scope line, and links to the topic files that hold the memories, or to
+sub-areas once the area gets crowded. Every topic file is reachable from
+the hub through an area. The cap then bounds the number of areas rather
+than the number of memories, and nothing has to be condensed or cut to
+fit.
+
+**Areas follow the dispatch table.** Each policy has an area named for
+it, such as `area_research.md` for `policies/research.md`, and so does
+each reserved scope in `policies/reserved/`, so the hub shows an agent
+every scope before it has rules. A lesson filed in a reserved area is a
+candidate for that scope's first rule (AGENTS.md §3). An owner area
+holds who the owner is and how they work, and repository areas are
+added as memories about parts of the code need them. When the dispatch
+table loads a policy, open its area as well; open the owner area on
+first contact. When a policy is added, renamed, or removed, its area
+follows, and the check reports an area that has fallen out of step.
+
+**What must apply every session is an instruction, not a memory.** A
+hub link is a route; it does not guarantee a read. A rule that has to
+hold in every session belongs in the instruction files the harness
+always loads, or in a policy through the accumulation loop.
+
+**Form is guard-enforced.** `scripts/provider-memory.mjs init` seeds the
+hub and areas from the policy files and never overwrites a file.
+`check` validates the hub and areas, reachability, link targets, the
+areas' coverage of the policies, and the hub's size against half the
+provider's cap. Its `hook` mode runs after each memory write in Claude
+Code (`claude-settings-additions.json`) and returns findings to the
+agent at once. An index that predates this shape is migrated before the
+hook is enabled, and the migration is an owner decision. Where the
+provider generates its memory itself, LORE neither seeds nor checks it.
+
+**Recall is not coordination.** A private memory of having claimed or
+finished something establishes neither; the shared record does (§3
+self-recognition, [orchestration policy §0](orchestration.md#0-configured-coordination)).
+Native memory is usually local to one machine and readable only by its
+own harness, and its scope may be one repository or every project the
+harness touches. Record each harness's location, scope, and LORE's use
+of it in the [provider memory table](../AGENTS.md#provider-memory).
+
+### Apply the Matching Checks
+
+The bundled `scripts/memory-lint.mjs` validates the bundled web's file
+format at its supplied repository root. It does not validate an
+agent-native or external store. The project's standard check suite
+(`verification.md` Rule 1) names the applicable provider checks, if any,
+and distinguishes unchecked capabilities from verified ones. The shipped
+template guard can still check the template without making it the active
+memory backend.
+
+## 1. What Memory Is
+
+The repository is the truth. Memory is the **map** — a shared, persistent,
+walkable web of links with a status overlay. An agent (or sub-agent) walks
+the web from the hub outward, each hop growing more specific, until it
+arrives at the place that says what needs work versus what is done, and
+where the details live.
+
+Memory never contains the specifics of a given edit, creation, or feature.
+It contains **links** — to repo paths, docs, ADRs, plans, journals,
+branches, PRs — and **status**. The moment a node starts explaining *how*
+something works instead of pointing at where that's recorded, it has
+drifted into being a second copy of the repo, and second copies rot.
+
+## 2. Shape — the Web
+
+```
+memory/
+  INDEX.md              ← the hub. Every walk starts here.
+  agents/
+    <agent-id>.md       ← one per primary agent (§3)
+  <area>.md             ← first-ring nodes: broad areas of the repo
+  <area>/
+    <subarea>.md        ← deeper rings: increasingly specific
+```
+
+- **The hub** (`memory/INDEX.md`) links every first-ring node, the agent
+  registry, and any structural decisions about memory itself (§6). It
+  carries no repo detail of its own.
+- **Area nodes** cover a broad concern — a domain, a subsystem, a
+  long-running arc. Each links deeper nodes, the owning repo paths, and
+  the governing docs.
+- **Leaf nodes** are the most specific: a feature, a migration, a
+  component family. This is where status lives at working granularity.
+
+Each node carries, in order:
+
+1. A one-line scope statement — what this node maps.
+2. A **link table** — where the relevant truth lives.
+3. A **status ledger** — dated entries (§4).
+4. A **claims section** — active and released claims
+   (`policies/orchestration.md`).
+
+Node granularity follows need, not symmetry. Rings grow when a node's
+ledger gets crowded enough that walkers can't find things — that crowding
+is the signal to split, by appending links to new child nodes.
+
+## 3. Identity, Registration, and Who Writes
+
+> **Erratum (2026-10-17, owner ruling on the registry):** The platform
+> registry records coordination identity: the exact full id used each
+> session, the model in use, claims, journal links, and sub-agent ids.
+> Its "longitudinal ledger" below is the lineage of that identity, not
+> the platform's continuity store. What an agent keeps for its own later
+> use belongs in its provider memory (§0); the state of a piece of work
+> resumes from its node and journal (`policies/orchestration.md` §5).
+> The self-recognition rule below still holds where a harness keeps
+> native memory: a claim is yours only by the exact id registered this
+> session, never because a private memory recalls taking it.
+
+**Identity is the platform — the harness, not the model.** Claude Code,
+Codex, Grok: whatever agent harness is running is the identity. Models
+swap inside a harness mid-session; the model in use is session metadata
+in the registry entry, never an identity segment, so a model change
+cannot orphan live claims.
+
+**Identity is a path, deepened only as uniqueness demands** — the same
+granularity principle as the web's rings. A discriminator's only job is
+uniqueness among *live* agents:
+
+- One live instance of a platform: the platform name is the whole id —
+  `claude-code`.
+- Multiple live instances of the same platform: each takes a
+  discriminator segment — **by assigned area when the work is
+  partitioned** (`claude-code/frontend`, `claude-code/backend`), **by
+  session date otherwise** (`claude-code/2026-08-30-a`). Area
+  discriminators are self-documenting but can drift if scope moves
+  mid-session; if an instance's work leaves its named area, coordinate
+  and re-register rather than working under a misleading name.
+- **Sub-agents carry the parent id plus their assigned task,** deepening
+  area → focus → file only as needed to be unique among live siblings:
+  `claude-code/research--frontend`, and only if two research subs share
+  an area, `claude-code/research--frontend--auth-forms`. Sub-agent ids
+  appear in journal names and the parent's session entry — never as
+  registry files.
+
+**One registry file per platform, not per instance:**
+`memory/agents/<platform>.md`. Sessions are dated appended entries, each
+recording the full id used that session (with any discriminator), the
+model in use, claims taken, journal links, and sub-agents spawned with
+their ids. The platform file is a longitudinal ledger of everything that
+platform has done in this repository — worth more than a directory of
+one-session fragments.
+
+**Self-recognition rule.** Agents have no memory across context windows.
+At session start, a primary appends its session entry **before its first
+claim**; thereafter, a claim is yours only if it carries the exact full
+id you registered this session. "That's my platform, so it's probably
+mine" is not recognition — a claim signed by your platform under a
+different or missing discriminator belongs to a sibling until
+coordination proves otherwise.
+
+- **The web itself is shared.** All primary agents append to the same hub
+  and nodes. There is no per-agent fork of the map.
+- A primary agent entering a repository with no web **bootstraps it** as
+  part of orientation: create the hub, register itself, and lay down
+  first-ring nodes for the areas it can already name. A sparse honest web
+  beats a speculative complete one — rings grow as work reaches them.
+- **Sub-agents read the web freely but do not register and do not claim.**
+  Their findings route through the parent agent, which appends on their
+  behalf under its own identity.
+
+## 4. Append-Only Discipline
+
+**No edits. No deletions. Ever.** The web's history is part of its value —
+a future agent reading a node should be able to see not just what is true
+but what used to be believed.
+
+- **Deprecation, not removal.** When a link or entry stops being true,
+  strike it through and stamp it, then append the replacement **in the
+  same slot, immediately adjacent** — never at the bottom of the file:
+
+  ```
+  - ~~[Write manager](src/fs/writeManager.js)~~ — deprecated 2026-08-30,
+    superseded by split below
+  - [Write pipeline](src/fs/pipeline/) — appended 2026-08-30
+  ```
+
+  Current truth must be findable where the old truth was. Making devs or
+  agents scroll to the bottom to discover the live link is a policy
+  violation, not a style choice.
+
+- **Status changes are new ledger lines,** dated, never rewrites of old
+  ones:
+
+  ```
+  - 2026-08-12 — in-progress — claimed, branch feat/example (agent-a)
+  - 2026-08-19 — done — merged PR #41, journal .research/2026-08-12-example.md
+  ```
+
+- Status vocabulary: `planned` · `in-progress` · `blocked` · `done` ·
+  `deprecated`. Extend it per repo if needed — by an appended dated note
+  in the hub, so every walker shares one vocabulary.
+
+**Node retirement — the entropy release valve.** Append-only means struck
+content accumulates, and a node whose dead weight drowns its live signal
+has stopped being a map. When a walker can no longer find current truth
+at a glance:
+
+1. **Spawn a successor node** carrying only the live links and the open
+   tail of the ledger, opening with a birth line:
+   `Successor of <old-node>, retired YYYY-MM-DD — full history there.`
+2. **Retire the old node with a banner at the TOP** — dated, pointing
+   forward to the successor — and never append to it again. It stays in
+   place as the archive.
+3. **Re-point the parents:** strike-and-stamp every hub and parent link
+   to the retired node, replacement in-slot pointing at the successor.
+
+Nothing is deleted; retirement is archival, so the append-only discipline
+holds. Note that splitting a crowded node into children (§2) is not a
+substitute — splitting copies the crowding into the children. Retirement
+is how dead weight actually leaves the walking path.
+
+**Form is guard-enforced.** `scripts/memory-lint.mjs` checks the
+mechanics this section defines — dated ledger lines, stamped strikes,
+well-formed claims and releases — and flags multiple live claims in one
+node. The script is the enforcement of record for the formats it checks
+(AGENTS.md §1); run it per `policies/verification.md`. What it cannot
+check is append-only itself: a stateless lint sees form, not history.
+That discipline remains on the agent.
+
+## 5. Git Status
+
+**Gitignored by default** (`memory/` in `.gitignore`), unless the owner
+says differently — that call is the owner's, made once and recorded in
+the hub.
+
+The tradeoff to surface when asking: ignored memory is invisible to other
+clones. The web coordinates only agents who can see it. Same working tree,
+no problem. Agents operating from separate clones or machines need the web
+committed (or otherwise synced) before parallel work starts —
+`policies/orchestration.md` §6.
+
+**Deciding late is the expensive direction.** The ignored→committed flip
+is retroactive and irreversible in one motion: every entry ever written
+becomes public simultaneously, and append-only means the back-history
+cannot be removed afterward — only struck, which leaves the text in
+place. Agents write into an ignored web with the working assumption that
+it is local operational state, so it accumulates internal names, machine
+paths, unreleased project names, and candid status notes at a standard
+no one set for publication.
+
+Therefore: **make this call before the web has a history, not after.** If
+the decision is deferred, treat the web as if it were already public
+while it stays undecided. And if a flip to committed is made on a web
+that already has depth, it is a review, not a toggle — read the whole
+web first, and treat anything unpublishable as a reason to keep it
+ignored rather than a thing to quietly restate.
+
+**Git worktrees are a special trap.** Worktree-per-agent is a common
+parallel-agent pattern, and each worktree is a separate working tree — a
+gitignored `memory/` does NOT propagate between worktrees of the same
+repository. Two agents working in sibling worktrees will each see (or
+each create) a private web while believing they share one, which defeats
+every coordination guarantee in `policies/orchestration.md`. Before
+parallel worktree work starts, one of: symlink `memory/` into every
+worktree from a single canonical location, commit the web, or don't run
+the agents in parallel. Owner call, recorded in the hub.
+
+## 6. Convention Evolution
+
+> **Addendum (2026-10-17, vendor memory has shipped):** Common harnesses
+> now ship first-party memory, and the alongside case below is the
+> standing arrangement: §0's provider-native subsection governs that
+> memory as a private layer. Making a provider's memory the shared
+> backend, or widening what LORE writes into it beyond pointers, remains
+> an owner decision recorded per §0.
+
+Memory conventions are lab-shaped and will keep changing. If a platform
+vendor (Anthropic, Cursor, or whoever) ships a first-party memory
+convention:
+
+- The new convention **may be discussed and adopted, or declined.** The
+  discussion happens with the owner; agents do not migrate memory
+  unilaterally.
+- The decision is **structural and locked per repo**: a dated entry in the
+  hub records what was adopted or declined and why.
+- A new convention may live as a **separate memory space alongside the
+  web** rather than replacing it. The web remains the authoritative map
+  until a dated hub decision says otherwise. Bridges between spaces (a
+  link from the hub into the new space) are cheap and preferred over
+  migration until the new convention has proven itself.
+
+## 7. What Memory Is Not
+
+- **Not a research journal.** Investigation state lives in `.research/`
+  per `policies/research.md`; nodes *link* journals.
+- **Not repo documentation.** ADRs, plans, and briefs live in `docs/` per
+  `policies/documentation.md`; nodes *link* them.
+- **Not a changelog.** Git history is the changelog.
+- **Not a scratchpad.** Nothing exploratory; the web records what has been
+  established and where to find it.

package/suite/policies/orchestration.md

@@ -0,0 +1,184 @@
+# Orchestration Policy
+
+Scoped agent-governance procedure (AGENTS.md §1/§2). Load whenever more
+than one agent may touch this repository in overlapping time, whenever
+starting or ending a session in a shared repository, and whenever work is
+being split across agents or handed off between them.
+
+**The coordination substrate is the memory web** (`policies/memory.md`).
+Claims live at memory nodes; there is no separate coordination board. One
+substrate serves as both map and ledger: an orchestrating agent assigns
+areas by writing claims at nodes, and a working agent walks to its node
+and sees scope, neighbors, status, and what is already done — in one
+place. If this unification stops fitting a project, the owner and agents
+may split the substrates; that is a structural decision recorded in the
+memory hub.
+
+> **Addendum (2026-10-17, owner-directed board):** The LORE board can be
+> configured as the work-status record (AGENTS.md §5,
+> `policies/board.md`). It is not the coordination board ruled out
+> above: it carries no claims. Claims, releases, and handoffs stay at the
+> configured coordination location, and a card may link the record that
+> holds its claim.
+
+## 0. Configured Coordination
+
+> **Erratum (2026-10-02, owner-directed memory adaptation):** Resolve the
+> coordination location in AGENTS.md §5 before using the web-specific
+> procedures below. Memory and coordination may share a provider or live
+> in separate places. The earlier single-web description is the bundled
+> default; a configured agent or company memory remains governed by its
+> own conventions.
+
+Use the configured shared location for sessions, scope claims, releases,
+dependencies, and handoff pointers. "Node" and "hub" refer to the web's
+logical navigation across providers; the concrete registry files and paths
+below describe the bundled implementation. Use the configured navigation
+mapping to find another provider's corresponding project area and records.
+Preserve exact claimant identity, scope, confirmation of the claim, visible
+release, and handoff evidence;
+the provider's supported representation governs the storage format.
+
+All participating agents must be able to see the same coordination state
+and confirm their claims there. Private agent memory, a read-only memory
+provider, or separate unsynced memories can still help orientation; record
+claims in the separately configured shared location. A project note or
+shared file can provide that location without a dedicated memory module.
+
+If no accessible shared location exists, sequence overlapping work through
+the owner. Do not infer another agent's agreement from a private claim.
+The configured provider's visibility and confirmation are what establish
+coordination; merely having a memory module does not establish them.
+
+> **Addendum (2026-10-02, navigation clarification):** A separate shared
+> coordination record is linked from the relevant working node in the web.
+> Walking from broad scope to specific work should reveal its claim and
+> handoff location even when that record and the memory use different stores.
+
+## 1. Roles
+
+- **Owner** — the human. Final authority on scope disputes, merge order,
+  and everything else.
+- **Orchestrator** — an optional coordinating agent. May partition work,
+  write claims on behalf of workers, and sequence merges. An orchestrator
+  is a convenience, not a requirement; the claim rules below work
+  peer-to-peer without one.
+- **Primary agents** — registered in `memory/agents/<platform>.md` under
+  the identity scheme of memory policy §3: platform-rooted path ids,
+  discriminated (by area or session date) only when multiple instances of
+  the same platform are live. Claim, work, release — always under the
+  exact full id registered this session.
+- **Sub-agents** — act under their parent's claim and identity. They never
+  claim, never register, and report findings to the parent, who appends to
+  the web on their behalf. Sub-agents DO keep their own research journals
+  (`policies/research.md` Rule 1) — a journal is lineage-named work
+  product, not registration.
+
+## 2. Claims
+
+A primary's session entry (memory policy §3) must exist **before its
+first claim** — every claim carries the exact full id registered for this
+session, and self-recognition depends on it.
+
+Before working an area:
+
+1. **Walk the web** to the most specific node that covers the intended
+   work.
+2. **Check the claims section** of that node and its parent ring.
+3. **Write a claim** — an appended, dated entry, timestamped to the
+   minute (claim ordering may need to be decided by it, step 4):
+
+   ```
+   - CLAIM 2026-08-30T14:02 — claude-code/frontend — scope: retry logic
+     in <path> — branch: feat/example — deliverable: PR
+   ```
+
+4. **Re-read the node and confirm the claim survived.** Checking and
+   writing are separate operations on a shared file: two agents can both
+   see a node unclaimed and both write, and one write can clobber the
+   other. After appending, read the node back and verify your claim is
+   present AND is the only live claim on that scope.
+   - Your claim is missing → the other write won the file. Do not
+     re-append; coordinate before touching the scope.
+   - Two live claims on the same scope → the earlier timestamp holds;
+     the later claimant strikes its own claim with a dated note and
+     yields. Identical or ambiguous timestamps → both stop and escalate
+     (§3).
+   - A detected conflict is the system working. A silent clobber is the
+     failure. This confirmation step is what converts one into the
+     other.
+
+5. Work. On completion or session end, **append a release**:
+
+   ```
+   - RELEASE 2026-08-31 — claude-code/frontend — done, PR #52;
+     remainder noted in ledger
+   ```
+
+Claims obey the memory policy's append-only discipline: released and
+superseded claims are struck and stamped, never deleted.
+
+**Claim the most specific node that covers the work.** A claim at an area
+node when the work touches one leaf blocks neighbors for no reason;
+matching claim granularity to node granularity is what lets parallel work
+happen at all.
+
+## 3. Conflicts
+
+- **Recognition is by exact full id** (memory policy §3). A claim signed
+  by your platform under a different or missing discriminator is a
+  *sibling's* claim, not yours — treat it as any other agent's active
+  claim until coordination proves otherwise.
+- **An active claim on your target means you do not work it.** Coordinate
+  with the claim holder (through the owner or orchestrator if there is no
+  direct channel), or take adjacent unclaimed work.
+- **Overlapping claims:** proceed only if the work is file-disjoint and
+  both claims note the overlap. Otherwise the later claimant yields.
+- **Agents never silently resolve scope disputes between themselves.**
+  Escalate to the owner or orchestrator with both claims stated plainly.
+- **Stale claims:** a claim with no ledger activity past the project's
+  threshold *(adopt-time slot — suggested default: one session or 24
+  hours, whichever the owner prefers)* may be flagged and superseded —
+  with a dated note naming the staleness, never silently. The prior
+  claimant's work-in-progress branch is left untouched; supersession takes
+  over the *scope*, not the branch.
+
+## 4. Partitioning
+
+- **Partition along architecture boundaries, not file lists.** Domains,
+  modules, subsystems — seams the codebase already respects. File-list
+  partitions leak the moment an interface changes.
+- **One unit of work, one branch, one agent** (`policies/git.md`). Two
+  agents on one branch is a merge accident with extra steps.
+- **Cross-claim dependencies get sequenced explicitly.** If B's work needs
+  A's merged first, that ordering is appended at the hub or a coordination
+  node — not held in anyone's context window.
+
+## 5. Handoff (absorbed scope)
+
+This policy owns the former standalone handoff scope. Ending a session
+mid-work:
+
+1. Append status to the owning node's ledger: what is done, what remains,
+   next actions in order.
+2. Link the research journal (`policies/research.md` — the journal is
+   where the detail lives; the node just points).
+3. Release the claim, or annotate it if the same agent expects to resume.
+
+A successor agent resumes from **node + journal, never from scratch**. If
+a successor cannot reconstruct the state of work from those two artifacts,
+the handoff was defective — codify what was missing as a rule here.
+
+## 6. Visibility Assumptions
+
+The web coordinates only agents who can see it.
+
+- **Default assumption: one shared working tree** (or clones on the same
+  machine sharing the `memory/` directory).
+- **Separate clones or machines:** the web must be committed or otherwise
+  synced before parallel work starts — see `policies/memory.md` §5. This
+  is an owner call. Running parallel agents against invisible-to-each-
+  other memory is how two agents claim the same scope in good faith.
+- Branch discipline (`policies/git.md`) is the backstop: even when
+  coordination fails, one-unit-one-branch keeps collisions reviewable
+  instead of destructive.