@dall337/lore 0.0.0-stage → 0.1.0

package/package.json

@@ -1,6 +1,54 @@
 {
   "name": "@dall337/lore",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.0",
+  "description": "LORE — Living Operational Rules & Evidence: a read-and-adapt governance suite for agent-driven development, with a local HUD for its board and journals.",
+  "keywords": [
+    "agents",
+    "governance",
+    "claude-code",
+    "codex",
+    "kanban",
+    "memory",
+    "policies",
+    "ai-agents"
+  ],
+  "homepage": "https://github.com/DalL337/agent-lore#readme",
+  "bugs": {
+    "url": "https://github.com/DalL337/agent-lore/issues"
+  },
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "lore": "bin/lore.mjs"
+  },
+  "files": [
+    "bin",
+    "suite",
+    "hud/dist"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/DalL337/agent-lore.git"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "prepack": "npm run build",
+    "build": "vite build --config hud/vite.config.ts && vite build --config hud/vite.config.ts --ssr server/main.ts",
+    "typecheck": "tsc -p hud/tsconfig.json",
+    "test": "node --test \"hud/test/*.test.ts\"",
+    "test:e2e": "npm run build && node hud/test/e2e/ui.e2e.mjs && node hud/test/e2e/cli.e2e.mjs",
+    "hud": "node bin/lore.mjs hud",
+    "demo": "npm run build && node hud/scripts/demo.mjs"
+  },
+  "devDependencies": {
+    "@fontsource/jetbrains-mono": "5.3.0",
+    "@types/node": "24.19.1",
+    "typescript": "7.0.2",
+    "vite": "8.3.2"
+  }
+}

package/suite/AGENTS.md

@@ -0,0 +1,228 @@
+# AGENTS.md — Agent Governance Entry Point
+
+> **Seed suite.** This governance suite was adopted from LORE — Living
+> Operational Rules & Evidence — and is expected to diverge. It is
+> read-and-adapt: when a rule here conflicts with this project's reality,
+> fix the rule — with a dated note — rather than working around it. The
+> transferable part is the method; the specifics are yours to earn.
+
+## 1. Purpose and Authority
+
+This file is the first thing an agent reads in this repository. Everything
+in it is either a policy to follow or a pointer to the document that owns
+the details.
+
+Order of authority:
+
+1. **Enforcement code** — guards, CI checks, and any ratified automated
+   gate. The enforced floor. When prose and enforcement disagree, the
+   enforcement wins and the prose gets fixed. The suite ships its first
+   guard: `scripts/memory-lint.mjs`, which checks memory-web form
+   (`policies/memory.md` §4). It is the model for what earned enforcement
+   looks like — as rules prove out, they graduate from prose to guards.
+2. **This file** — repository-wide process policy and the dispatch maps
+   below.
+3. **`policies/*`** — scoped procedures. Mandatory when a dispatch row
+   matches the task; they own execution detail within their scope.
+4. **Agent judgment** — governs everything the above does not. Judgment is
+   not a fallback of last resort; it is the default state of an
+   ungoverned scope, and the source of every future rule (§3).
+
+## 2. Two Maps
+
+An agent's first question is which map applies.
+
+### 2.1 Greenfield — repository birth
+
+If this repository has no established stack (no tooling register exists):
+
+1. Load `policies/tooling.md`. Take the owner's PRD, or create one first.
+2. Research candidates, build the tooling proposal, present it. The
+   owner's decisions birth the **tooling register** — the living record
+   every future stack question references.
+3. Load `policies/memory.md`. Resolve the memory configuration (§5), use
+   the established system when one exists, and bootstrap the bundled web
+   only when that is the chosen backend.
+4. Scaffold. Steady state begins.
+
+### 2.2 Steady state — policy dispatch
+
+Read the work request, match it against this table, and load ONLY the
+policies the task needs — never the whole suite. A policy loads BEFORE
+the work it governs begins. Failure to load a matching policy is an
+execution error.
+
+| When the task involves… | Load and follow |
+|---|---|
+| First contact with this repo; configuring, reading, or writing repository memory | `policies/memory.md` — resolve the configured web entry point (§5), then walk the relevant rings; bootstrap the bundled files only when selected |
+| Research, investigation, debugging, architecture discovery, repository exploration, documentation review, root-cause analysis | `policies/research.md` — **before the first tool call** (journal-first) |
+| Writing or changing code (any language) | `policies/implementation.md` |
+| Branching, committing, pushing, opening PRs | `policies/git.md` |
+| Preparing any PR, completing a milestone/slice, changing an API or architecture boundary | `policies/verification.md` |
+| Creating or updating repo documents (ADRs, plans, briefs, PRDs, notes) | `policies/documentation.md` |
+| Release work: version bumps, bundling, release builds | `policies/release.md` |
+| Security-relevant work: new execution/network surface, supply-chain features, audit passes | `policies/security.md` |
+| Owner-requested adversarial deep dive; creating or changing an enforcement point or a guarantee about state ownership, lifetime, or ordering | `policies/adversarial-check.md` — trace the guarantee through the system before calling the slice done or opening its PR |
+| Owner-invoked creative mode; exploring an inventive direction, an unusual connection, or an unfinished idea | `policies/creative.md` — develop possibilities with the owner; evaluation begins when requested |
+| More than one agent may touch this repo; starting or ending a session in a shared repo; handing work off | `policies/orchestration.md` (with `policies/memory.md`) |
+| Starting, moving, or finishing a unit of work when the board is the work-status record; filling an empty board | `policies/board.md` |
+| Adding, upgrading, or replacing dependencies, frameworks, or languages; any stack question | `policies/tooling.md` |
+
+A task matching multiple rows loads multiple policies. A code slice that
+ends in a PR loads implementation + git + verification; an investigation
+that produces an ADR loads research + documentation; a dependency swap
+loads tooling + security + git.
+
+> **Addendum (2026-10-17, provider memory areas):** Where a harness lets
+> the agent write its own memory index, loading a policy also opens that
+> policy's area from the index's hub (`policies/memory.md` §0).
+
+## 3. Provenance and Accumulation
+
+This suite ships with **no incident history — deliberately.** The rules
+below the entry point are starting principles distilled from a real
+repository's lessons, with the incidents stripped. Your project's rules
+will be earned here, on this repository, and they will carry their
+origins.
+
+**The accumulation loop is mandatory:**
+
+1. A lesson emerges — a bug ships, a check gets skipped, an audit finds a
+   loophole, a workflow fails in a way a rule would have prevented.
+2. The agent drafts the rule in the policy that owns the scope, carrying
+   the date and a description of the incident that produced it.
+3. The owner ratifies, amends, or rejects. Ratified rules are policy.
+4. The suite grows in place. Rules carry their origin on purpose: a rule
+   whose origin you can read is a rule you can argue with when it stops
+   fitting.
+
+**Amendment discipline:** accepted rules grow by dated addenda and
+corrections, never silent rewrites. History stays legible in the document
+itself. (Full conventions: `policies/documentation.md`.)
+
+**Housekeeping:** keep this suite free of personal or account data —
+names, email addresses, account IDs, machine paths, third-party
+identities. Rules describe *behavior* and cite roles ("the owner") and
+artifacts (PR numbers, scripts, ADRs). Identity values live in local
+config and agent memory, never in these files.
+
+> **Addendum (2026-10-01, owner-directed policy expansion):** Added
+> `policies/creative.md` for collaborative exploration and
+> `policies/adversarial-check.md` for investigation of concrete guarantees.
+> Their dispatch rows above define the triggers. Creative exploration
+> moves into evaluation when the owner asks for it or selects a concrete
+> proposal to develop.
+
+> **Addendum (2026-10-02, owner-directed memory adaptation):** Memory may
+> use the bundled web, an established agent or company system, or another
+> location. The memory configuration in §5 is the entry point for that
+> choice. Existing company and project conventions govern their stores;
+> the bundled web's layout applies when that backend is selected.
+
+> **Erratum (2026-10-02, owner clarification of the web):** The web's
+> progression from repository categories to increasingly specific nodes is
+> retained across providers. Configuration selects its storage and
+> navigation mapping. A thin pointer index can expose those routes over
+> existing agent or company memory without replacing its records.
+
+> **Addendum (2026-10-17, owner-directed provider memory):** A harness's
+> own memory coexists with the configured backend as a private layer
+> governed by its provider's conventions. LORE writes only pointers into
+> it, and anything another agent needs stays in the shared layer. Where
+> the agent writes the provider's index, that index is a links-only hub
+> over areas named for the policies, reserved scopes included, checked
+> by `scripts/provider-memory.mjs`. The provider memory table in §5
+> records each harness's store and LORE's use of it.
+
+> **Addendum (2026-10-17, instruction budget):** Codex reads at most
+> 32 KiB of `AGENTS.md` files along the path to its working directory and
+> stops reading the rest. `scripts/agents-md-budget.mjs` holds every such
+> chain under 30 KiB, leaving room for a global file. When an addendum
+> would push past the budget, move its detail into the policy that owns
+> the scope and leave a pointer here.
+
+## 4. Reserved Scopes
+
+Empty policy files exist for scopes with no rules yet:
+
+`planning` · `review` · `test-authoring` · `migration` ·
+`failure-and-recovery`
+
+An empty policy means no rules exist for that scope: proceed on general
+judgment and this file, and when a lesson emerges, codify it there (with
+provenance) rather than growing this file.
+
+New scopes are allowed. When the first rule of a new kind needs a home,
+create the stub in `policies/reserved/`, add its dispatch row, and place
+the rule.
+
+Two scopes from the ancestor suite were retired on generalization, their
+duties absorbed: **dependency-change** lives in `policies/tooling.md`
+(steady-state arm); **handoff** lives in `policies/orchestration.md` §5.
+
+## 5. Adaptation Slots
+
+Read-and-adapt means most of this suite works as shipped, but a handful of
+decisions are the adopting project's to make. Fill these deliberately, and
+early — each is flagged at its site:
+
+- **Tooling register + license allowlist** — `policies/tooling.md` §2.
+  The first register entry is the allowlist.
+- **Standard check suite** — `policies/verification.md` Rule 1. Enumerate
+  the project's actual commands.
+- **Merged-branch stance** (delete vs retain) — `policies/git.md` §1.4.
+- **Version string locations** — `policies/release.md` Rule 1. Enumerate
+  every file that carries the version.
+- **Memory storage and web entry point** — fill the memory configuration below;
+  `policies/memory.md` §0 owns selection and coexistence. For the bundled
+  web, also decide ignored vs committed per its §5. List each harness's
+  native memory in the provider memory table below.
+- **Stale-claim threshold** — `policies/orchestration.md` §3.
+- **Markdown lint stance** — `policies/documentation.md` Rule 6.
+- **Work status** — memory-node ledgers or the LORE board
+  (`policies/board.md`); record the choice in the memory configuration
+  below.
+
+Keep the dispatch table in sync with what actually exists. A row pointing
+at a policy this project deleted is a trap for the next agent.
+
+### Memory Configuration
+
+*(Adopt-time slot, added 2026-10-02.)* Record the chosen configuration in
+this table, or replace it with a pointer to the project or company document
+that owns the configuration. Honor an established choice before creating
+a new store. These fields are prompts to fill, not a requirement to adopt
+the bundled module.
+
+| Field | Record on adoption |
+|---|---|
+| Storage provider | Bundled LORE files, agent-native/company memory, or an external store. |
+| Web entry point | The repository-relative path, document reference, URI, or supported tool entry point for the repository's navigation hub. The bundled files start at `memory/INDEX.md`. |
+| Navigation mapping | How broad repository categories lead through increasingly specific nodes to authoritative records; use provider links/categories or a thin index that points into the chosen store. |
+| Scope and access | The repository's namespace or area; which agents can read and write; visibility across sessions, worktrees, and clones. |
+| Coordination location | The same backend when it supports shared, verifiable claims; otherwise a separate shared file or service. |
+| Work status | Where each unit of work's status lives: the web's node ledgers, or the LORE board (`.lore/board.json`, `policies/board.md`), whose cards the nodes then link. |
+| History and checks | The chosen provider's update/retention rules and the checks available for its records. |
+| Fallback | An approved alternate location or how unavailable memory is reported; no silent competing store. |
+
+An agent-native entry point that exposes the repository web can be used
+directly. The bundled file module is optional; the navigation can use a
+provider's own structure or a thin pointer index in another location.
+An external store may be as small as a shared project note with those routes.
+The [memory policy](policies/memory.md#0-configured-memory) defines how
+these choices interact with the suite's default conventions.
+
+### Provider Memory
+
+*(Adopt-time slot, added 2026-10-17.)* One row per harness that works in
+this repository. A harness's native memory is its private layer
+([memory policy §0](policies/memory.md#coexist-with-provider-native-memory)):
+the provider's conventions govern it, and LORE writes only pointers
+there. The seeded rows describe two harnesses as their vendors
+documented them in October 2026. Confirm against current documentation,
+and remove rows for harnesses this project does not use.
+
+| Harness | Native memory | Written by | Load cap | LORE writes there | Visibility |
+|---|---|---|---|---|---|
+| Claude Code | [Auto memory](https://code.claude.com/docs/en/memory#auto-memory): `~/.claude/projects/<project>/memory/`, a `MEMORY.md` index with one file per memory. On by default. | The agent, during sessions | First 200 lines or 25KB of `MEMORY.md` each session; other files on demand | The hub and area indexes, links only, checked by `scripts/provider-memory.mjs` | One machine; shared by the repository's worktrees |
+| Codex | [Memories](https://developers.openai.com/codex/memories): `~/.codex/memories/`, or under `CODEX_HOME`. Off by default. | Codex, in the background from past chats | Summary truncated to about 2,500 tokens ([openai/codex#48679](https://github.com/openai/codex/issues/48679)); `AGENTS.md` chain 32 KiB | Nothing; `AGENTS.md` is the pointer channel, held under 30 KiB by `scripts/agents-md-budget.mjs` | One machine; repository scoping undocumented |

package/suite/CLAUDE.md

@@ -0,0 +1,19 @@
+@AGENTS.md
+
+# CLAUDE.md
+
+This repository's agent governance lives in **[AGENTS.md](AGENTS.md)**,
+imported above.
+
+Read it first, in full, before any other action. It carries the authority
+order, the two maps (greenfield vs steady state), and the policy dispatch
+table that says which of `policies/*` to load for the task at hand.
+
+This file exists only as a pointer for harnesses that look for
+`CLAUDE.md` by convention. `AGENTS.md` is the entry point of record; if
+the two ever disagree, `AGENTS.md` wins and this file is what gets fixed.
+
+> **Correction (2026-10-17):** Added the import line. Claude Code reads
+> `AGENTS.md` on its own only when no `CLAUDE.md` is present, so a
+> prose-only pointer here left loading `AGENTS.md` to the agent's
+> discretion. The import loads it at session start.

package/suite/claude-settings-additions.json

@@ -0,0 +1,16 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node",
+            "args": ["${CLAUDE_PROJECT_DIR}/scripts/provider-memory.mjs", "hook"]
+          }
+        ]
+      }
+    ]
+  }
+}

package/suite/gitignore-additions.txt

@@ -0,0 +1,17 @@
+# LORE — append the default-location rules you use to your .gitignore.
+# Added 2026-10-02: these are the default in-repo locations. Resolve
+# AGENTS.md's memory configuration first; /memory/ is only needed when
+# using the bundled web. Adapt ignore paths for chosen local locations;
+# external or agent-native memory needs no extra memory directory.
+#
+# Do NOT copy this file in as your .gitignore, and do not paste these
+# without the leading slashes: an unanchored `memory/` matches at EVERY
+# level, so it would silently ignore a src/memory/ module in your own
+# source tree. The leading slash anchors each rule to your repo root.
+
+# Agent memory web — gitignored by default; owner decision to commit
+# (policies/memory.md §5). Record the decision in memory/INDEX.md.
+/memory/
+
+# Research journals — in-tree, never committed (policies/research.md)
+/.research/

package/suite/memory/INDEX.md

@@ -0,0 +1,41 @@
+# Memory Hub
+
+Entry point to this repository's memory web (`policies/memory.md`).
+Every walk starts here. Append-only: strike-and-stamp deprecations,
+replacements in-slot.
+
+> **Addendum (2026-10-02, configurable memory):** This hub is the bundled
+> module's entry point. First resolve the memory configuration in AGENTS.md
+> §5; an established agent/company memory or external location can be the
+> selected home instead. Bootstrap and register here only when this web is
+> selected. A copied template is not evidence that it is the active store.
+
+> **Erratum (2026-10-02, navigation clarification):** This file is one
+> implementation of the repository hub. The same category-to-specific-node
+> walk is preserved in the chosen provider or a configured pointer index.
+
+## Structural Decisions
+
+> **START HERE — decide this before writing anything else.**
+>
+> **Is `memory/` committed, or gitignored?** Shipped default is
+> **ignored**: add `/memory/` to your `.gitignore` — keep the leading
+> slash, or it also matches `src/memory/`. Then delete this box and
+> replace it with a dated entry saying what you chose.
+>
+> **Decide now, while this web is empty.** It is append-only, so the flip
+> from ignored to committed publishes everything ever written here, all at
+> once, and nothing can be removed afterward. Until you choose, write as
+> if this web were already public.
+>
+> Tradeoffs and full reasoning: `policies/memory.md` §5.
+
+- (dated entries: git status of memory/, convention adoptions, vocabulary extensions)
+
+## Agents
+
+- (links to `memory/agents/<platform>.md` as platforms register — one file per platform, sessions as dated entries)
+
+## Areas
+
+- (links to first-ring nodes as they are laid down)

package/suite/policies/adversarial-check.md

@@ -0,0 +1,169 @@
+# Adversarial Check Policy
+
+Scoped agent-governance procedure (AGENTS.md §1/§2). Load for an
+owner-requested adversarial deep dive, or before calling a slice done or
+opening its PR when it creates or changes an enforcement point or a
+guarantee about state ownership, lifetime, or ordering. These are starting
+principles; this project's own findings and lessons accumulate here with
+their provenance.
+
+This policy triggers a fresh investigation through the system. State the
+important guarantees, trace the actual behavior that supports them, and
+actively seek counterexamples. Use the implementation, its explanation,
+and its tests as evidence to investigate. A convincing account or a green
+test suite does not establish what its evidence never exercised.
+
+## Rule 1 — Scope Follows the Guarantee
+
+Applies to access and disclosure decisions; trust-boundary parsing and
+validation; resource limits; check-then-act operations; concurrency fences;
+and state or lifecycle signals another module relies on, such as "ready,"
+"loaded," "saved," or "still current." It also applies to a review target
+the owner explicitly selects for an adversarial deep dive.
+
+Routine styling, copy, and changes outside these guarantees do not trigger
+the pass. Security-review obligations remain in the
+[security policy](security.md); the normal check suite remains in the
+[verification policy](verification.md).
+
+Include upstream and downstream code the selected guarantee depends on,
+even when that code predates the slice or lives in another module. If a
+consumer trusts a signal, the producer and the conditions under which it
+emits that signal are in scope. Trace until the guarantee has a supported
+foundation or a concrete unresolved assumption.
+
+Record unrelated findings separately, with their severity and evidence.
+Keep their repair outside the slice unless the owner expands its scope.
+
+## Rule 2 — Investigate Independently
+
+Reconstruct behavior from the real entry points and execution paths.
+Use the author's account to orient the investigation, then establish each
+important claim through source inspection and, where possible, execution.
+Read reused helpers and callers; follow transformations, ownership changes,
+and side effects across module boundaries.
+
+Actively look for the missing connection: individually reasonable pieces
+can rely on incompatible assumptions when composed. Inspect what tests
+substitute or hand directly to a consumer. A test that supplies a ready
+signal establishes behavior under that supplied signal; investigate whether
+the real producer emits it under the correct conditions.
+
+The author or a reviewer can perform this pass. A second agent is optional;
+do not spawn subagents by default. Independent investigation is required
+regardless of who performs it.
+
+## Rule 3 — The Deep Dive
+
+1. **State the claims.** Write one sentence per important guarantee,
+   including guarantees implied by the interface. Identify the input,
+   state, or observable outcome it covers.
+2. **Trace the full chain.** Follow the real input through normalization,
+   checks, state transitions, side effects, and consumers. Locate the
+   producer of every trusted signal and the object ultimately acted on.
+   Cite the relevant paths and symbols.
+3. **Expose the assumptions.** Identify what must be true about identity,
+   timing, ownership, ordering, platform behavior, and failure handling.
+   Establish where each condition is enforced. Keep an unsupported
+   assumption visible as an investigation target.
+4. **Explore alternate paths.** Trace other routes to the same effect,
+   including retries, reopening, cancellation, restoration, errors, and
+   stale work completing after a context switch. Apply Rule 4's questions
+   where they affect the guarantee.
+5. **Construct counterexamples.** Choose inputs and transitions that could
+   invalidate those assumptions. Exercise the real chain where practical.
+   For a race, introduce a test seam inside the exact check/use window and
+   change the state there; a change made before the check does not exercise
+   that window. Use disposable fixtures for destructive scenarios.
+6. **Demonstrate the failure.** Run a suspected reproduction against the
+   unfixed code. Preserve the script or test, observed output, revision,
+   and relevant environment. If execution is impractical, record why and
+   keep the finding qualified under Rule 5.
+7. **Verify the repair.** Run the same reproduction, unchanged, against the
+   fix. Verify each affected platform or environment where behavior differs;
+   name outstanding coverage explicitly. Examine new assumptions introduced
+   by the fix, including a second-order failure in its own checks.
+
+## Rule 4 — Questions That Open the Trace
+
+These questions are prompts for investigation. Follow the relevant answer
+into the code and behavior; checking a box is not evidence.
+
+- **Identity and lifetime.** Is the object checked the object used? Can a
+  name, alias, copied identifier, counter, or reopened session identify a
+  different object or generation? What survives a context switch?
+- **Check versus use.** What can change after validation or authorization
+  and before the operation? Is the eventual handle, snapshot, or state still
+  covered by the check? Does resolving a name change which object is acted
+  on?
+- **Producer versus consumer.** Does a signal certify work its producer
+  actually completed for this context? Trace synchronous completion,
+  delayed completion, empty data, restoration, cleanup, and re-entry.
+- **Ordering and refusal.** Can state announce success before a refusable
+  side effect succeeds? What happens after partial failure, cancellation,
+  duplicate execution, or a late result?
+- **Bounds.** Are limits enforced on what is actually read, allocated,
+  processed, and emitted, including encoding, aggregate work, and concurrent
+  callers? Exercise the exact limit and the smallest input beyond it.
+- **Alternate routes and observations.** Can another operation produce the
+  guarded effect? Can names, counts, errors, or timing expose something
+  withheld? Follow the exception and effect-equivalent-path method in
+  [security policy Rule 4](security.md#rule-4--chokepoint-exceptions-inherit-every-exemption).
+- **Failure and platform differences.** What do missing state, failed OS
+  queries, unsupported behavior, and each supported platform do to the
+  guarantee? For a permission decision, an unresolved check must refuse.
+  Distinguish the behavior actually exercised from behavior inferred by
+  inspection.
+
+## Rule 5 — Evidence Status
+
+Every finding has an explicit status. Report only what its evidence proves.
+
+| Status | Meaning | Required evidence |
+|---|---|---|
+| **Suspected** | Inspection or reasoning indicates a possible failure. | The claim, source references, and a proposed reproduction. |
+| **Reproduced** | The unfixed code demonstrated the failure. | A repeatable test or script, observed output, revision, and relevant environment. |
+| **Verified fixed** | The same reproduction succeeds against the repair. | The unchanged reproduction and the run proving the corrected behavior in each claimed environment. |
+
+A source-inspection finding begins as `suspected`, including a peer
+reviewer's finding. A property established only by inspection is reported
+as `suspected, confirmed by inspection`, with its citations; it is not
+called reproduced. A passing functional test does not establish a resource
+bound that it never measured.
+
+When behavior differs by platform or environment, qualify status for each.
+A repair that has not been exercised is described as `fix applied,
+unverified`, alongside the last established finding status. Do not report
+it as verified fixed.
+
+A failed reproduction attempt stays in the record. Keep the finding
+suspected, or explicitly withdraw it with the evidence and reason. Failure
+to reproduce does not establish safety. State the status whenever the
+finding is reported in a journal, PR, or conversation.
+
+## Rule 6 — Budget and Completion
+
+Perform one pass per selected guarantee per slice; repeat for guarantees
+affected by later changes. Scale the number of guarantees and experiments
+to the change and its consequences. Keep each selected guarantee's trace
+deep enough to examine its dependencies. Do not replace that investigation
+with a shallow checklist to meet a line count or time budget.
+
+A plausible disclosure, write, execution, data-loss, or wrong-context
+failure needs a deliberate reproduction attempt and before/after evidence
+for its repair. Lower-impact concerns can remain suspected with a clear
+note. If a trace cannot be completed within the available scope, record the
+unresolved assumption and what would establish it; do not call that
+guarantee verified.
+
+Log the pass in the slice's research journal under the
+[research policy](research.md). Record the guarantees, the important trace
+references, short attack verdicts, findings with their statuses, and
+remaining gaps. A PR summary links that record and states material findings
+and unresolved verification.
+
+Planted mistakes remain useful for checking the failures already imagined.
+This pass actively searches for additional failure modes. When a later
+review finds a flaw the pass should have caught, append the project's own
+lesson with its date, provenance, evidence, and the question or tracing
+habit it sharpens, following AGENTS.md §3.

package/suite/policies/board.md

@@ -0,0 +1,103 @@
+# Board Policy
+
+Scoped agent-governance procedure (AGENTS.md §1/§2). Load when the LORE
+board is this repository's work-status record (AGENTS.md §5, memory
+configuration) and the task starts, moves, or finishes a unit of work;
+and when the board is empty or missing and the owner wants it filled.
+
+*(Added 2026-10-17, owner-directed: the board generalizes a project
+kanban into LORE. Its first rule is that project's standing owner rule,
+"keep the board current".)*
+
+## 1. What the Board Is
+
+The board (`.lore/board.json`, shown by `lore hud`) holds one card per
+unit of work, in a column that says where the work stands. It is private
+by default: `.lore/` stays out of git unless the owner opts in.
+
+- **It is a status record, not a coordination substrate.** Claims stay at
+  the configured coordination location (`policies/orchestration.md` §0).
+  A card may link the node or record that holds the claim.
+- **It points; it does not explain.** Detail lives in journals, docs,
+  decision records, and PRs. A card's notes are a line or two.
+- **When the board is the status record, memory nodes link cards** rather
+  than keeping a second status ledger for the same work.
+- **Cards never point into a harness's private memory.** Provider memory
+  may point at card ids (`policies/memory.md` §0); anything another agent
+  needs goes on the card, in a journal, or in a doc.
+
+## 2. Keep It Current
+
+When work moves, update the board in the same session:
+
+| The work… | The card… |
+|---|---|
+| starts | exists in the active column, linked to its journal |
+| opens a PR | links the PR |
+| waits on the owner (review, ruling, merge, live pass) | moves to the review column |
+| waits on something outside the repository | moves to blocked, with a one-line note |
+| merges or ships | moves to done, with its PRs linked |
+
+With the HUD running, use its API so the open page updates at once:
+`POST /api/board/card` with `{ "card": { … } }` creates or updates,
+`POST /api/board/move` with `{ "id", "column", "index" }` moves. Without
+it, edit the file and keep it valid JSON; the HUD never overwrites a file
+it cannot parse. A session that cannot write the board (a read-only
+review, a worktree without `.lore/`) reports the implied changes instead.
+
+## 3. Bootstrap an Empty Board
+
+When the board is empty or missing and the owner asks to fill it:
+
+1. **Journal first** (`policies/research.md`): the survey is an
+   investigation.
+2. **Read the repository:** README, docs and decision records, open PRs
+   and issues (`gh`), recent history and branches, TODO and FIXME
+   markers, existing journals.
+3. **Propose areas:** the repository's broad categories, the same first
+   ring as the memory web. Each is a short key and a one-line
+   description.
+4. **Propose cards:** units of work with their evidence links, each in a
+   column. Open PRs, open issues, and active journals already appear in
+   the HUD's Inbox; make those cards from the Inbox rather than by hand.
+5. **Write only what the owner approves**, then link the journal from the
+   cards it produced.
+
+## 4. The Board File
+
+```jsonc
+{
+  "version": 1,
+  "columns": [
+    // role tells the HUD what a column means: intake (issues land here),
+    // active (journals), review (PRs, owner's attention), blocked, done.
+    // Each role is on at most one column; a column may have none.
+    { "id": "doing", "title": "In progress", "led": "pulse", "hint": "Active now", "role": "active" }
+  ],
+  "areas": { "api": "Public API: endpoints, SDK, versioning" },
+  "cards": [
+    {
+      "id": "rate-limits",                 // unique; a readable slug
+      "title": "Rate limits on the public API",
+      "column": "next",                    // a column id
+      "area": ["api"],                     // area keys
+      "notes": "One or two lines.",
+      "links": {
+        "journals": ["2026-10-06-rate-limits.md"],  // in the journals folder
+        "prs": [108], "issues": [12],
+        "docs": ["docs/adrs/004-rate-limits.md"]    // repo-relative
+      },
+      "created": "2026-10-06", "updated": "2026-10-11"
+    }
+  ]
+}
+```
+
+- Card order within a column is the order of the `cards` array.
+- Moving work: change `column` and bump `updated`.
+- In an update, a field left out keeps its value; `null` clears it.
+- LEDs: `empty` · `blue` · `pulse` · `amber` · `red` · `green`.
+- The HUD rejects duplicate ids, unknown columns, a role on two columns,
+  and cards without an id or title.
+- `journals` (owner close marks) and `inboxDismissed` belong to the HUD;
+  leave them to it.