@event4u/agent-config 6.0.0 → 7.0.0

package/docs/decisions/ADR-093-ai-council-config-user-global.md

@@ -0,0 +1,111 @@
+---
+adr: 093
+status: accepted
+date: 2026-06-13
+decision: ai-council-config-user-global
+supersedes: —
+superseded_by: —
+phase: ai-council-config-relocation
+type: structural
+---
+
+# ADR-093 — Relocate the AI-council config to the user-global namespace
+
+## Status
+
+**Accepted** · 2026-06-13. Maintainer directive (standing, restated): the
+council is a per-developer facility and must be configured once, globally,
+not re-declared per project.
+
+## Context
+
+The council config (`.ai-council.yml`) was a **project-tracked** file at
+`agents/settings/.ai-council.yml`, checked into this repository (it held the
+maintainer's enabled members + `file:`/`env:` key references). Resolution was
+anchored on the project root (`council_cli.py:AI_COUNCIL_FILE = REPO_ROOT /
+"agents" / "settings" / ".ai-council.yml"`; `cmd_doctor.py` recomputed the
+same path).
+
+Three defects followed from the project-tracked layout:
+
+1. **Per-project, not per-developer.** A single developer who wants the
+   council everywhere had to drop the file into every project — exactly the
+   opposite of "configure once".
+2. **Commit / leak risk.** The config sat in the tracked tree of a public
+   package; only the `file:`/`env:` indirection (raw keys are refused by
+   `_validate_api_key_ref`) kept secrets out.
+3. **Silent unavailability.** On any surface without a project copy — cloud /
+   headless / a fresh checkout / a different worktree — resolution found
+   nothing and the council refused with "ai_council.enabled is false", even
+   when the developer had set it up. The raw API keys already lived in the
+   user-global namespace (`~/.event4u/agent-config/<provider>.key`, resolved
+   by `resolve_api_key`); only the config that points at them did not.
+
+The user-global namespace helper (`scripts/_lib/user_global_paths.py`,
+`event4u_root()` → `~/.event4u/agent-config/`, with the legacy
+`~/.config/agent-config/` read-fallback) already underpinned key resolution,
+so the config had a natural home there.
+
+## Decision
+
+**The council config is user-global by default.** A single
+`resolve_config_path(project_root)` in `scripts/ai_council/config.py` is the
+one place that decides which file is read, with this precedence
+(first match wins):
+
+1. `$AI_COUNCIL_CONFIG` — explicit absolute path (tests / power users);
+   honoured even when absent, so typos surface as "create it here".
+2. Project-local `<project_root>/agents/settings/.ai-council.yml` — a
+   consumer project that deliberately checks in its own config; overrides
+   the user-global file for that project only.
+3. User-global `~/.event4u/agent-config/settings/.ai-council.yml` (legacy
+   `~/.config/agent-config/` read-fallback) — the canonical default.
+
+When none exists, the resolver returns the user-global write target so
+callers' `.exists()` gate and "create it at …" messaging both point at the
+global location.
+
+`council_cli.py` and `cmd_doctor.py` both route through this resolver. The
+tracked `agents/settings/.ai-council.yml` is removed from the repository; the
+documented shape ships as `agents/templates/.ai-council.yml.example` to copy
+from. The maintainer's live config now lives at
+`~/.event4u/agent-config/settings/.ai-council.yml`.
+
+Project-local override is **kept** (not removed) so a consumer team can still
+pin a shared council config in their own repo — but it is no longer the
+default, and this package no longer ships one in its tracked tree.
+
+## Consequences
+
+- The council now resolves from the user-global file in every project,
+  worktree, and CWD — verified: a worktree with no project copy resolves
+  `~/.event4u/agent-config/settings/.ai-council.yml` and reports `members=2`.
+- No council config can be silently committed to this (or any consumer)
+  public repo by default.
+- `doctor council-cli` now names the user-global path in its
+  "no council config" / "config invalid" messaging.
+- The test suite is made hermetic via `EVENT4U_CONFIG_HOME` sandboxing so
+  it never reads the developer's real global config (it otherwise would,
+  now that "no project file" falls through to global).
+- **Not done here (follow-up):** auto-scaffolding the global file from the
+  example template during `agent-config` install/setup. Resolution +
+  manual/templated placement satisfy "the package always uses it"; an
+  installer step that writes the example to the global path when absent is
+  a nice-to-have tracked separately to keep `install.py` out of this diff.
+
+## Alternatives
+
+- **Global always wins, ignore project files.** Rejected — it would break a
+  consumer team's legitimately checked-in shared council config. Removing
+  this package's tracked copy already gives the maintainer global-everywhere
+  behaviour without taking the override away.
+- **Keep the file project-tracked, just gitignore it.** Rejected — still
+  per-project, still absent on fresh/cloud surfaces; does not deliver
+  "configure once per user".
+
+## References
+
+- Contract: [`docs/contracts/ai-council-config.md`](../contracts/ai-council-config.md) § File location.
+- `scripts/ai_council/config.py:resolve_config_path` — the resolver.
+- `scripts/_lib/user_global_paths.py` — user-global namespace + legacy fallback.
+- `agents/templates/.ai-council.yml.example` — the documented shape to copy.

package/docs/decisions/ADR-094-agent-memory-layer-removal.md

@@ -0,0 +1,94 @@
+---
+adr: 094
+status: accepted
+date: 2026-06-14
+decision: agent-memory-layer-removal
+supersedes: —
+superseded_by: —
+phase: memory-layer-cleanup
+type: structural
+---
+
+# ADR-094 — Remove the heavyweight agent-memory layer; keep file-first memory
+
+## Status
+
+**Accepted** · 2026-06-14. Resolved by three AI-council rounds
+(claude-sonnet-4-5 + gpt-4o) on 2026-06-14; maintainer-directed package
+optimization.
+
+## Context
+
+Engineering memory in this suite had **two layers**:
+
+- **Layer 1 — file-first (in this repo).** Curated YAML under
+  `agents/memory/<type>/` + agent-written `agents/memory/intake/*.jsonl`,
+  read through `scripts/memory_lookup.retrieve()`. Git-tracked, lintable,
+  redactable, vendor-neutral. No external infrastructure.
+- **Layer 2 — the `@event4u/agent-memory` companion package (separate repo).**
+  PostgreSQL + pgvector, an MCP server, Ebbinghaus decay, trust scoring, and
+  cross-project learning. Consumed optionally via a versioned cross-repo
+  contract; `scripts/memory_lookup.py` exposed an `operational_provider` seam,
+  `scripts/memory_status.py` probed for the package CLI, and the MCP tools
+  routed through it when "present".
+
+The package was unused, its integration roadmaps were already archived, and
+its external repository is being deleted. Native agent memory (Claude, Cursor)
+is improving on the exact axis — semantic cross-session recall — where the
+package competed, and its PostgreSQL + MCP runtime contradicted the suite's
+"no app runtime" positioning.
+
+## Decision
+
+1. **Remove Layer 2 entirely** from `agent-config` — the package binding and
+   the now-dead generic operational machinery it alone served:
+   `package_operational_provider` / `_cli_operational_provider`, the
+   `operational_provider` parameter, the `OperationalProvider` type, the
+   repo-vs-operational conflict rule, `Shadow` / `with_shadows` /
+   `shadowed_by`, the package-detection in `memory_status.py`, the MCP
+   `with_package` routing, and the `agent-memory-contract.md` contract doc.
+2. **Keep Layer 1** — file-first `retrieve()`, the `check_memory.py` redaction
+   gate, and the typed curated/intake store. This is *governance* (auditable,
+   portable, reviewable), a different job from native memory.
+3. **Simplify contract artefacts in-place, do not loudly break.** The internal
+   `retrieval-v1` schema + conformance suite were reduced to repo-only
+   (`source: "repo"`; no `operational` / `trust` / `shadowed_by`) rather than
+   version-bumped, because the only consumer (the package) is deleted.
+4. **Adopt MemSkill's write-time curation discipline** (Apache-2.0,
+   github.com/ViktorAxelsen/MemSkill) into the `memory-consolidation` skill —
+   dedupe before insert, split distinct facts, merge-and-preserve on update,
+   delete only on explicit contradiction, prefer no-op under uncertainty, skip
+   trivial/fleeting/speculative. The ML training/eval pipeline is **not**
+   adopted; MemSkill's own thesis (quality comes from write-time skills, not a
+   heavy storage substrate) reinforces the removal.
+
+## Consequences
+
+- One memory layer, file-backed, smaller surface, no infra prerequisite.
+- `memory_status.status()` is now a constant file-backend report; `health()`
+  still emits the v1 envelope shape so the MCP `memory_status` tool is stable.
+- No decay engine → committed memory is bounded manually (intake gitignored,
+  type narrowing, entry caps, archived-entry deletion — see
+  `road-to-memory-pipeline-consolidation.md`).
+- The memory ADR area (`docs/adrs/memory/`) is retired from
+  `audit_adr_coverage.py`; ADR 0001 there is marked superseded by this ADR.
+
+## Alternatives considered
+
+- **Freeze Layer 2 (leave inert).** Rejected — a dormant integration surface
+  advertising a capability the suite no longer has is misleading residue.
+- **Markdown-only (drop the YML layer too).** Rejected — the working
+  `retrieve()` machinery + the `check_memory.py` redaction gate are real
+  governance a schema-less markdown parser cannot cheaply replace; an 8-consumer
+  migration is untested risk for no gain (council, Option B).
+- **Revive Layer 2 later.** Gated: requires ≥2 funded consumer projects with a
+  named maintainer each + explicit PostgreSQL adoption.
+
+## References
+
+- `agents/roadmaps/archive/road-to-agent-memory-removal.md` — the executing roadmap (archived).
+- `agents/roadmaps/archive/road-to-memory-pipeline-consolidation.md` — follow-on
+  mining consolidation + size bounding.
+- `docs/adrs/memory/0001-consumer-side-snapshot.md` — superseded by this ADR.
+- `docs/guidelines/agent-infra/memory-access.md` — the surviving file-backed
+  retrieval contract.

package/docs/decisions/ADR-095-workspace-boundary-contract.md

@@ -0,0 +1,108 @@
+---
+adr: 095
+status: accepted
+date: 2026-06-14
+decision: workspace-boundary-contract
+supersedes: —
+superseded_by: —
+phase: v6.0.0 · final-readiness · Phase 4
+type: structural
+---
+
+# ADR-095 — Workspace boundary contract + import-edge drift check
+
+## Status
+
+**Accepted** · 2026-06-14. Lands Phase 4 of
+[`road-to-6.0.0-final-readiness`](../../agents/roadmaps/archive/road-to-6.0.0-final-readiness.md).
+Routed through the AI council (anthropic/claude-sonnet-4-5 + openai/gpt-4o,
+design mode, 2026-06-14; converged 2-round on "import-boundary linter as MVP
+with explicit semantic-drift disclaimer + escape-hatch").
+
+## Context
+
+The PR #489 / 6.0.0 review flagged that **"workspace" risks becoming the new
+"meta"** — a catch-all that absorbs every nearby concern until it owns
+everything and means nothing. The workspace is real and load-bearing (13
+`src/cli/python/workspace_*.py` modules behind `/work` and the host-drive
+loop), so the risk is concrete: a future change quietly teaches a workspace
+module to design skills, decide profile semantics, or pick video providers,
+and the boundary erodes one import at a time.
+
+The prior council finding (#3 on the parent roadmap) accepted a boundary
+contract **with modification**: this repo has no dependency-cruiser /
+TS-import-boundary tooling, so any drift mechanism must *fit the real surface*
+or *explicitly justify doc-governance-only*.
+
+## Decision
+
+1. **Author a boundary contract** at
+   [`docs/contracts/workspace-boundary.md`](../contracts/workspace-boundary.md)
+   enumerating what the workspace **owns** and **does not own**.
+2. **Drift mechanism = an import-edge linter** (`scripts/lint_workspace_boundary.py`),
+   AST-static, over `src/cli/python/workspace_*.py`. It fails if a workspace
+   module imports an owner-module of a *not-owned* domain. It is wired into CI.
+3. **Explicit scope disclaimer.** The linter enforces **import edges only**.
+   Semantic drift — a workspace module encoding profile semantics or analytics
+   *product strategy* without importing anything forbidden — is **not**
+   catchable by an import check and stays **doc-governance**, enforced in
+   review against the contract. The contract states this limit plainly so the
+   green check is never mistaken for "the boundary is fully enforced" (the
+   council's named false-confidence risk).
+4. **Escape hatch.** A `# boundary-exception: <reason>` pragma on the import
+   line lets a justified, reviewed exception through; the contract records that
+   such pragmas are reviewed like any boundary change.
+
+### Owns / does-not-own (locked by the parent roadmap's council)
+
+| Workspace **owns** | Workspace **does NOT own** |
+|---|---|
+| task orchestration | skill design |
+| host-session lifecycle | profile semantics |
+| continuation (multi-turn) | video-provider logic |
+| drive health | MCP-registry policy |
+| | analytics **product strategy** |
+
+## Consequences
+
+- The boundary becomes a CI gate, not a wish-list. Day-one state: **zero
+  violations** (survey below), so the check locks the current-correct boundary
+  rather than papering over drift.
+- The import check is cheap and precise here because workspace modules live in
+  `src/cli/python/` and the not-owned owner-modules live in `src/scripts/` —
+  separate namespaces, no false-positive surface (workspace modules import only
+  stdlib, third-party `keyring`/`cryptography`/`yaml`, and intra-workspace
+  `workspace_*`).
+- Semantic drift remains a review responsibility; the contract names it so
+  reviewers know the linter is a supplement, not a substitute.
+
+## Survey — existing violations
+
+AST import survey of all 13 `workspace_*.py` modules (2026-06-14):
+
+- The only cross-module import is `workspace_inbox → workspace_skills`
+  (intra-workspace; allowed).
+- **Zero** imports of any skill-design / profile / pack / video / MCP /
+  condense / router / persona owner-module.
+- `workspace_skills.py` *resolves* skill bodies for host hand-off (consumes,
+  does not design) → within bounds.
+- `workspace_analytics.py` records task completion/abandonment telemetry
+  (drive-health domain, not analytics product strategy) → within bounds.
+
+**Result: zero boundary violations recorded.**
+
+## Alternatives
+
+- **Doc-governance-only (no check).** Rejected as the sole mechanism: the
+  surface is concrete Python with clean namespaces, so the cheapest lock (an
+  import check) earns its keep against the most common drift vector. Kept as
+  the mechanism for *semantic* drift, which an import check cannot see.
+- **dependency-cruiser / TS import-boundary tooling.** N/A — the workspace
+  surface is Python, not TS; importing JS tooling for it is wrong-stack.
+
+## References
+
+- [`docs/contracts/workspace-boundary.md`](../contracts/workspace-boundary.md) — the contract.
+- [`scripts/lint_workspace_boundary.py`](../../src/scripts/lint_workspace_boundary.py) — the drift check.
+- [`ADR-050`](ADR-050-workspace-vs-package-root-boundary.md) — the workspace-vs-package-root trust boundary this refines at the module level.
+- [`docs/contracts/daily-workspace.md`](../contracts/daily-workspace.md) — cross-links this contract.

package/docs/decisions/ADR-096-analysis-workbench.md

@@ -0,0 +1,110 @@
+---
+adr: 096
+status: accepted
+date: 2026-06-15
+decision: analysis-workbench
+supersedes: —
+superseded_by: —
+phase: road-to-analysis-workbench · Phase 0
+type: structural
+---
+
+# ADR-096 — Analysis Workbench design decisions
+
+## Status
+
+**Accepted** · 2026-06-15. Lands Phase 0 of
+[`road-to-analysis-workbench`](../../agents/roadmaps/archive/road-to-analysis-workbench.md).
+Routed through AI council (anthropic/claude-sonnet-4-5 + openai/gpt-4o,
+two rounds, 2026-06-15).
+
+## Context
+
+A new `analysis-workbench` pack was proposed to close the post-incident
+learning loop: structured post-mortem → root-cause analysis → corrective-action
+design → memory candidates → human-gated promote. Several design questions
+required council input before authoring any skill.
+
+## Decision
+
+### D1 — Collapse the skill set
+
+Council converged on four skills for v1:
+
+| Skill | Purpose |
+|---|---|
+| `blameless-post-mortem` | Structured post-incident review |
+| `root-cause-frameworks` | RCA engine (5-whys, fishbone, fault-tree, STAMP) |
+| `premortem` | Pre-launch risk elicitation |
+| `decision-review` | Retrospective decision quality |
+
+`incident-pattern-analysis` is **deferred** — it needs cross-project data the
+memory layer does not yet support reliably.
+
+### D2 — Internal-skill-heavy, not command-heavy
+
+The pack surfaces ≤ 5 visible commands (all opt-in). Complex orchestration
+lives inside skill bodies, not in a command DSL or state-machine orchestrator
+(deferred).
+
+### D3 — `/analyze` as confidence-weighted suggester, not auto-triage
+
+`/analyze` proposes candidate flows with confidence weights. The user picks.
+It does NOT auto-triage or auto-route. Selection choices are logged to the
+provisional intake stream so future iterations can tune weights from real usage.
+
+### D4 — Memory loop is manual; promote gate is inviolable
+
+The hardest pushback in both council rounds was against any auto-promote path.
+Decision: the loop produces and proposes; `scripts/check_memory_proposal.py`
+is the sole admission gate (≥2 distinct paths OR ≥3 future decisions);
+the human runs `/memory promote`. No skill, hook, or roadmap step may
+bypass this gate. See [`analysis-memory-loop.md`](../contracts/analysis-memory-loop.md).
+
+### D5 — AI-specific RCA deferred
+
+AI-specific failure modes (prompt injection, model hallucination root-cause,
+latency regression attribution) require `road-to-security-hardening` primitives
+that do not yet exist. Deferred explicitly; `root-cause-frameworks` ships
+without them.
+
+### N1 — Time-decay is a Phase 1 hardening item (adopted)
+
+Council named time-decay, supersession, and dedup pre-check as Phase 1 work
+(not blockers for Phase 0 contract authoring). The contract captures the
+schema now so Phase 1 has a stable target:
+
+- `last_validated` + `review_after_days` + `applicable_scope` on every candidate.
+- `retrieve()` returns `{results, skipped}` — stale entries are in `skipped`,
+  never silently included in `results`.
+- Dedup: `retrieve()` before draft; on match, propose `frequency`/`supersedes`
+  update, not a new entry.
+
+## Consequences
+
+- Phase 0 ships two authoring artifacts: `docs/contracts/analysis-memory-loop.md`
+  and this ADR. No skills, no code.
+- Phase 1 (memory-loop hardening) implements the schema fields and `retrieve()`
+  contract documented in `analysis-memory-loop.md` § 1 and § 4.
+- The pack uses pack identifier `analysis-workbench`, `size_class: medium`,
+  `cross_workspace: true`.
+- Domain adoption gates do not fire: the analysis domain is already open
+  (`incident-commander`, `risk-officer`, `decision-record`,
+  `systematic-debugging` exist in the suite).
+
+## Alternatives
+
+- **Auto-promote on ≥ 2 occurrences** — rejected both rounds. Silent learning
+  loop is a trust and auditability risk; human gate is non-negotiable.
+- **State-machine orchestrator** — deferred. Premature before skills ship and
+  real usage patterns emerge.
+- **`incident-pattern-analysis` in v1** — rejected. Needs cross-project memory
+  access not available in v1; deferred to a follow-up roadmap.
+- **Flat command surface (>5 commands)** — rejected per command-surface-tiers
+  contract; opt-in pack stays lean.
+
+## References
+
+- [`docs/contracts/analysis-memory-loop.md`](../contracts/analysis-memory-loop.md) — the loop contract.
+- [`docs/contracts/low-impact-corpus-format.md`](../contracts/low-impact-corpus-format.md) — curated memory schema.
+- [`ADR-094`](ADR-094-agent-memory-layer-removal.md) — agent memory layer decision this pack operates within.

package/docs/decisions/ADR-097-mission-recipe-privilege-boundary.md

@@ -0,0 +1,121 @@
+---
+adr: 097
+status: accepted
+date: 2026-06-15
+decision: mission-recipe-privilege-boundary
+supersedes: —
+superseded_by: —
+phase: road-to-mission-mode · Phase 0
+type: security
+---
+
+# ADR-097 — Mission recipes vs user recipes — privilege boundary
+
+## Status
+
+**Accepted** · 2026-06-15. Lands Phase 0 of `road-to-mission-mode`.
+Council-flagged risk: a user recipe smuggling a file-edit skill into a
+trusted mission's gated sequence.
+
+## Context
+
+Mission-Mode introduces two artifact classes that compose AC skills:
+
+1. **Mission recipes** — shipped in `src/missions/*`, version-controlled,
+   reviewed, and released as part of the AC package.
+2. **User / cookbook recipes** — authored by consumers in their own
+   `agents/missions/` or via the cookbook pattern; not package-controlled.
+
+Both can invoke `/work` directives and, in principle, reference AC skills
+by name. Without a privilege boundary, a user recipe could inject an
+arbitrary skill (e.g. a file-write or secrets skill) between the gated
+steps of a trusted mission, bypassing the human-gate sequence the mission
+was designed around. This is a privilege-escalation vector analogous to
+a confused-deputy attack.
+
+The `lethal-trifecta-guard` rule (private-data + untrusted-content +
+external-comms) identifies this shape as the canonical high-risk agent
+pattern. A user recipe that can call any skill is a potential trifecta
+assembler.
+
+## Decision
+
+### Trusted missions (`src/missions/*`) — TRUSTED tier
+
+- May invoke any AC skill directly by name in their phase sequence.
+- May read `inputs`, `catalog`, and `verification` fields from their manifest.
+- Shipped, reviewed, and signed off as part of AC's release process.
+- The manifest schema (`src/scripts/schemas/mission.schema.json`) governs
+  their structure; the linter enforces it.
+
+### User / cookbook recipes — SANDBOXED tier
+
+- **May** invoke trusted missions by name (e.g. `/mission:upgrade`).
+- **May** invoke other user recipes.
+- **May NOT** inject arbitrary AC skills between a trusted mission's steps.
+- **May NOT** reference a skill unless that skill's frontmatter declares
+  `user_invokable: true`.
+- The `user_invokable` frontmatter key does not exist yet; it is reserved
+  for the Phase 2 skill-annotation pass. Until Phase 2 ships, user recipes
+  may invoke missions only — no direct skill invocation at all.
+
+### Enforcement surface
+
+| Layer | Mechanism |
+|---|---|
+| **Linter** | `scripts/lint_mission_recipes.py` (Phase 2) checks that recipe files under `agents/missions/` do not reference skills lacking `user_invokable: true` |
+| **Schema** | `mission.schema.json` covers trusted missions; a separate `recipe.schema.json` (Phase 2) will cover user recipes |
+| **Rule** | `lethal-trifecta-guard` remains the runtime defense; the privilege boundary is a pre-execution authoring gate |
+| **Code review** | PRs adding `user_invokable: true` to any skill require the security-sensitive-stop review flow |
+
+## Rationale
+
+A user recipe that can call arbitrary skills can assemble the lethal
+trifecta (read secrets → pass through untrusted web content → write to
+filesystem) without the human-gate sequence a trusted mission provides.
+Sandboxing user recipes to missions-only until `user_invokable` is
+annotated keeps the threat surface minimal during Phase 0 and Phase 1,
+when the execution model is still a validation PoC.
+
+The `user_invokable` annotation approach (rather than a blanket allow/deny
+at the recipe layer) lets the suite grow the safe surface incrementally as
+each skill is audited — consistent with how `allowed_tools` works in skill
+execution blocks.
+
+## Consequences
+
+### Accepted
+
+- User recipes in Phase 0 and Phase 1 are limited to mission invocation
+  only. This is intentional — Phase 1 is a PoC, not a product.
+- Skill authors who want their skill callable from user recipes must
+  explicitly opt in via `user_invokable: true` after security review.
+- The linter gate ships in Phase 2, not Phase 0. Phase 0 is authoring-only;
+  no executable recipes exist yet.
+
+### Trade-offs
+
+- More friction for power users who want to compose skills in recipes.
+  Mitigation: the `user_invokable` path provides an explicit, auditable
+  escape hatch rather than a blanket block.
+- `user_invokable` key adds one more frontmatter field to the skill schema.
+  Cost is low (one boolean); benefit is a machine-checkable privilege
+  boundary.
+
+## Alternatives considered
+
+- **Allow user recipes to invoke any skill.** Rejected — directly creates
+  the privilege-escalation vector this ADR is designed to prevent.
+- **Block user recipes entirely.** Rejected — removes a legitimate power-user
+  use case and makes the sandbox permanent rather than an interim gate.
+- **Runtime enforcement only (lethal-trifecta-guard).** Rejected as
+  insufficient — runtime detection is a safety net, not a substitute for
+  authoring-time prevention, which is AC's stated differentiator.
+
+## References
+
+- `docs/contracts/no-runtime-boundary.md` — the boundary contract missions operate within
+- `src/scripts/schemas/mission.schema.json` — trusted mission manifest schema
+- `.agent-src.uncondensed/rules/lethal-trifecta-guard.md` — runtime defense layer
+- `.agent-src.uncondensed/rules/security-sensitive-stop.md` — review gate for `user_invokable` additions
+- `agents/roadmaps/archive/road-to-mission-mode.md` § Phase 0 — authoring context