@lamentis/naome 1.3.0 → 1.3.2

package/templates/naome-root/docs/naome/codex-hooks.md

@@ -0,0 +1,82 @@
+# Optional Codex Hooks
+
+NAOME can install repo-local Codex hooks as an optional acceleration layer for coding agents.
+
+Hooks are not the source of truth. They provide earlier feedback before an agent spends tokens on work that normal NAOME gates would reject later.
+
+Authoritative enforcement remains in:
+
+- `.naome/task-state.json` validation
+- `naome route`
+- `naome quality` and `naome semantic` gates
+- `naome commit`
+- repository Git hooks
+- verification proof checks
+
+## Install Or Skip
+
+`naome install` and `naome sync` may ask whether to install optional Codex hooks.
+
+Answering no is valid. The repository remains fully usable for humans, CI, and agents without Codex hook support.
+
+For non-interactive environments, NAOME skips optional hooks unless explicitly requested:
+
+```sh
+NAOME_CODEX_HOOKS=1 naome sync
+NAOME_CODEX_HOOKS=0 naome sync
+```
+
+## Events
+
+The installed dispatcher listens to these Codex events:
+
+- `UserPromptSubmit`: performs read-only prompt classification and repo/task inspection. Codex Desktop currently accepts no non-blocking warning decision here, so advisory output is intentionally silent.
+- `PreToolUse`: blocks clear unsafe commands before execution, including destructive Git operations, hook bypasses, force pushes, `.naome/archive` reads, `.naomeignore` reads, and broad searches that do not honor NAOME search boundaries. It also runs commit/push preflight checks.
+- `PostToolUse`: after edits, records changed-file state, narrows checks to files touched by the current tool call when Codex provides a path, compares those files with active task ownership, checks repository-model freshness, and runs cheap path-scoped gates. Non-blocking edit guidance is cached for later Stop/preflight decisions rather than emitted as an unsupported warning.
+- `PermissionRequest`: performs read-only escalation risk classification. Codex Desktop currently accepts no non-blocking warning decision here, so advisory output is intentionally silent.
+- `Stop`: prevents misleading completion claims when scope drift, stale repository-model data, missing proof, an unpushed requested branch, or unresolved requested review comments are still visible.
+
+## Blocking And Advisory Checks
+
+Hard blocks are reserved for clear safety violations:
+
+- destructive commands such as hard resets, forced cleans, and deleting `.git`
+- hook bypasses such as `--no-verify`
+- force pushes, including `--force`, `--force-with-lease`, and `-f`
+- reads or searches inside `.naome/archive` or paths matched by `.naomeignore`
+- broad search commands that fail NAOME search-profile validation
+- commit/push attempts that would skip required ownership, scope, proof, or repository-model checks
+- final responses that would claim completion while required proof or scope checks are still failing
+
+Hook output is conservative for Codex Desktop compatibility: hooks emit `{}` for allowed/advisory outcomes and emit only `{"decision":"block","reason":"..."}` for true blocks. Stable reason codes are embedded in the block reason text.
+
+## Edit-Time Gates
+
+After file edits, hooks run only fast deterministic gates. When the tool input identifies touched files, PostToolUse scopes these checks to those files instead of the whole diff:
+
+- `git diff --check -- <touched-paths>`
+- `node .naome/bin/naome.js quality check --path <touched-path>`
+- `node .naome/bin/naome.js semantic check --path <touched-path>`
+- active-task scope checking for the touched paths
+
+If the touched paths cannot be inferred, PostToolUse falls back to the current changed-file set. These checks are debounced by the current diff signature plus the checked path set. Repeated hook calls over the same content reuse the previous result so normal editing stays responsive.
+
+Stop, commit, and push preflight stay full-diff checks. They verify the complete changed-file set so earlier unrelated drift or proof failures cannot be hidden by a later narrow edit.
+
+Full suites such as installer tests, Rust builds, package dry-runs, and CI-like workflows are treated as owed proof based on changed paths. They are not run automatically after every edit because they are too slow and noisy for real-time feedback.
+
+Every hook advisory calculation maps to a normal NAOME command or gate. If hooks are unavailable, disabled, or not installed, humans can keep working by following the normal route, context-selection, task-state, quality, semantic, verification, and commit gates directly.
+
+## Local Files
+
+Opting in installs:
+
+- `.codex/config.toml`
+- `.codex/hooks.json`
+- `.naome/bin/codex-hook.js`
+- `.naome/bin/codex-hook-io.js`
+- `.naome/bin/codex-hook-policy.js`
+- `.naome/bin/codex-hook-runtime.js`
+- `docs/naome/codex-hooks.md`
+
+These files are repo-local. They are managed only after opt-in and are not required by repositories that decline hooks.

package/templates/naome-root/docs/naome/context-economy.md

@@ -0,0 +1,73 @@
+# Context Economy
+
+NAOME reduces agent token use by selecting task context before broad reading.
+
+## Commands
+
+- `node .naome/bin/naome.js workflow agent-plan --json` returns the full
+  deterministic run-control bundle for the current task: execution plan,
+  context delta, proof plan, capability graph, edit watchdog, and decision
+  gate.
+- `node .naome/bin/naome.js context select --prompt-file <path> --json`
+  selects context from explicit file/path mentions in a user request.
+- `node .naome/bin/naome.js context select --changed --json` selects context
+  from the current diff.
+- `node .naome/bin/naome.js context select --prompt <text> --json` is useful
+  for diagnostics and small local prompts.
+
+## Output
+
+The selector returns:
+
+- `requiredContext`: read these files first.
+- `optionalContext`: read only when required context is insufficient.
+- `forbiddenContext`: paths that must not be used as agent context.
+- `capsule`: compact task type, such as `quality-work` or `source-work`.
+- `commands`: early path-scoped checks plus final changed gates.
+- `budgetLedger`: selected file count, avoided file count, estimated lines, and
+  estimated tokens.
+
+## Agent Rule
+
+After routing a task, run context selection and read only `requiredContext`.
+Do not read broad NAOME docs just because they exist. Use `optionalContext`
+only when blocked, and prefer path-specific commands such as
+`repo explain --path`, `structure explain --path`, and
+`quality check --path`.
+
+## Run-Control Models
+
+The agent-run plan combines seven token-saving models:
+
+- Execution plan ledger: ordered read, edit, quality, progress, and proof
+  steps for the active task.
+- Context delta: which already-read files are reusable, stale, or still
+  required.
+- Proof planner: the next minimal checks in verification phase order, with
+  broad checks withheld until earlier gates pass.
+- Output digest: stable command summaries that keep exit code, command, cwd,
+  relevant lines, affected paths, and artifacts without expanding full logs.
+- Capability graph: machine-readable languages, build systems, adapters, roots,
+  and verification edges.
+- Edit-session watchdog: path-scoped quality commands and scope-drift findings
+  for touched files.
+- Decision gate: `continue`, `create_task`, `ask_human`, or `stop` with reason
+  codes.
+
+Use the focused subcommands when only one model is needed:
+
+```text
+node .naome/bin/naome.js workflow context-delta --read-path <path> --json
+node .naome/bin/naome.js workflow proof-plan --json
+node .naome/bin/naome.js workflow capabilities --json
+node .naome/bin/naome.js workflow edit-watchdog --path <path> --json
+node .naome/bin/naome.js workflow decision-gate --json
+node .naome/bin/naome.js workflow digest --command <cmd> --exit-code <code> --output-file <path> --json
+```
+
+## Why Runs Get Faster
+
+Agent runs become faster because fewer files are loaded, fewer long outputs are
+expanded, and quality or structure issues are caught while the touched file is
+still small. The final changed-file gates remain required; context selection is
+an early feedback and read-boundary tool, not a replacement for verification.

package/templates/naome-root/docs/naome/first-run.md

@@ -30,21 +30,32 @@ context.
 
 1. Read `.naomeignore` and exclude every matched path from intake.
 2. Inspect existing repository instructions and docs, including README,
-   contributing docs, architecture docs, agent instruction files, and CI config.
-3. Detect stack, frameworks, package managers, project layout, entrypoints,
-   test tools, lint/typecheck/build commands, and deployment hints.
-4. Identify risky areas such as auth, billing, secrets, migrations, production
+   contributing docs, agent instruction files, and CI config.
+3. Refresh deterministic repository facts with
+   `naome repo model --write --json`. This records stack, package managers,
+   source roots, test roots, generated roots, and verification ids in
+   `.naome/repository-model.json`.
+4. Detect entrypoints, test tools, lint/typecheck/build commands, deployment
+   hints, and sensitive areas that are not yet derivable from deterministic
+   files.
+   Run `naome quality reconcile --json` after policy files exist; if detected
+   repository signals require missing adapters, use
+   `naome quality reconcile --write` so quality and structure policy match the
+   observed stack.
+5. Identify risky areas such as auth, billing, secrets, migrations, production
    config, customer data, generated files, or fragile inherited code.
-5. Build the Proof Harness:
+6. Build the Proof Harness:
    - inspect package files, build files, Makefiles, and CI workflows
    - record real checks in `.naome/verification.json`
-   - mirror the human-readable map in `testing.md`
+   - keep `testing.md` as a human-readable view, not the source of truth
    - run the fastest safe check when possible and record the result
    - preserve the JSON keys and allowed values documented below
-6. Fill `repo-profile.md`, `testing.md`, `architecture.md`, and `security.md`.
-7. Ask the user for critical missing product intent, forbidden zones, or
+7. Fill only the minimal human-readable notes still needed in `repo-profile.md`,
+   `testing.md`, `architecture.md`, and `security.md`. Do not duplicate facts
+   that already live in deterministic JSON.
+8. Ask the user for critical missing product intent, forbidden zones, or
    verification commands only if repository evidence is insufficient.
-8. Update `.naome/init-state.json`:
+9. Update `.naome/init-state.json`:
    - use `intakeStatus: "complete"` and `initialized: true` only when the
      completion gate is satisfied
    - use `intakeStatus: "needs_user_context"` and keep `initialized: false`
@@ -57,11 +68,11 @@ context.
 Initialization is complete only when:
 
 - `repo-profile.md` describes this specific repository.
-- `testing.md` records at least one real verification path.
-- `.naome/verification.json` contains the same durable checks and change-type
-  rules recorded in `testing.md`.
-- `architecture.md` describes observed structure and known or assumed
-  boundaries.
+- `.naome/repository-model.json` is current.
+- `.naome/verification.json` contains durable checks and change-type rules.
+- `testing.md` records a readable summary of the real verification paths.
+- `architecture.md` records only structure or boundaries that are not already
+  represented in deterministic model or structure policy.
 - `security.md` records sensitive areas or states that none are known yet.
 - remaining unknowns are explicit.
 

package/templates/naome-root/docs/naome/index.md

@@ -13,18 +13,23 @@ for the current step.
 6. `execution.md`, before accepting or completing feature work
 7. `first-run.md`, only when `initialized` is `false`
 8. `upgrade.md`, only when upgrade `status` is `needs_agent_upgrade`
-9. `repo-profile.md`
-10. `architecture.md`
-11. `testing.md`
+9. `.naome/repository-model.json`
+10. `context-economy.md`, when selecting task context
+11. `repository-model.md`, when stack, build, or path facts matter
 12. `.naome/verification.json`
-13. `repository-quality.md`, when repository-quality checks or cleanup are relevant
-14. `repository-structure.md`, when path roles or structure cleanup are relevant
-15. `security.md`
-16. `agent-workflow.md`
-17. `decisions.md`, when changing durable project policy
+13. `repo-profile.md`, only for legacy human-readable project notes
+14. `architecture.md`, only for legacy human-readable project notes
+15. `testing.md`
+16. `repository-quality.md`, when repository-quality checks or cleanup are relevant
+17. `repository-structure.md`, when path roles or structure cleanup are relevant
+18. `security.md`
+19. `agent-workflow.md`
+20. `decisions.md`, when changing durable project policy
 
 ## Source Types
 
+- Deterministic repository facts live in `.naome/repository-model.json` and are
+  refreshed with `naome repo model --write`.
 - Discovered facts come from repository files and commands.
 - Confirmed facts were explicitly confirmed by a human or existing
   authoritative documentation.
@@ -33,8 +38,11 @@ for the current step.
 
 ## Context Rule
 
-Do not load every NAOME document by default. Start from this index, then open the
-smallest set of files needed for the task.
+Do not load every NAOME document by default. Run
+`node .naome/bin/naome.js context select --prompt-file <path> --json` after
+routing natural-language work, or `node .naome/bin/naome.js context select
+--changed --json` for an existing diff. Read `requiredContext` first and
+`optionalContext` only when blocked.
 Do not search for generic root `ARCHITECTURE.md` or `docs/index.md` files unless
 this repository's NAOME docs explicitly reference them.
 

package/templates/naome-root/docs/naome/repository-model.md

@@ -0,0 +1,92 @@
+# Repository World Model
+
+The repository model is the deterministic source for machine-readable facts
+about this repository. It keeps stack and layout facts out of free-form
+Markdown so agents can make repeatable decisions.
+
+## Files
+
+- `.naome/repository-model.json` stores canonical facts.
+- `.naome/verification.json` stores runnable checks and change-type proof
+  policy.
+- Repository-quality and repository-structure policy store quality adapters and
+  layout rules.
+- Markdown documents explain workflow and summarize human context; they are not
+  the primary store for build, stack, or path-role facts.
+
+## Commands
+
+- `naome repo model --write --json` refreshes the model from repository files.
+- `naome repo check --json` verifies the committed model is current.
+- `naome repo explain --path <path> --json` explains the role and language for a
+  path using the canonical model.
+
+## Facts
+
+`naome.repository-model.v2` keeps the backward-compatible flat `facts[]` list
+and adds typed world-model sections. `naome.repository-model.v1` remains
+readable; new writes prefer v2.
+
+Flat facts are deterministic records with stable ids:
+
+- `language:<value>`
+- `packageManager:<value>`
+- `buildSystem:<value>`
+- `sourceRoot:<path>`
+- `testRoot:<path>`
+- `docsRoot:<path>`
+- `generatedRoot:<path>`
+- `artifactRoot:<path>`
+- `verificationCheck:<id>`
+
+Each fact includes evidence paths and a source. Do not hand-edit generated facts
+as normal workflow. Refresh them with the command above.
+
+## World Sections
+
+The v2 model stores typed sections so agents do not need to infer repository
+shape from prose:
+
+- `languages`, `packageManagers`, and `buildSystems`
+- `adapters` detected from deterministic stack signals
+- `roots` for source, test, docs, generated, and artifact paths
+- `entities` for packages, apps, and modules
+- `pathFacts` for significant paths with role, module, entity, language, and
+  generated/artifact flags
+- `verificationChecks` copied from `.naome/verification.json`
+
+These sections are generic and adapter-extensible. Product defaults must not
+contain repository-specific exceptions.
+
+## Agent Rule
+
+When a task depends on the stack, package manager, build system, source roots,
+test roots, generated roots, or verification ids, read or refresh the repository
+model instead of searching broad Markdown files. If the model is stale, update it
+first, then continue with the task.
+
+For a specific path, use:
+
+```text
+naome repo explain --path <path> --json
+```
+
+The explanation returns the canonical role, language, module, entity, matching
+facts, and evidence for that path.
+
+## Drift Gates
+
+NAOME does not silently rewrite `.naome/repository-model.json` during normal
+gates. Instead, stale facts are reported deterministically:
+
+- `naome doctor --json` reports a stale repository model section.
+- `node .naome/bin/check-task-state.js --progress` blocks active work until the
+  model is refreshed.
+- `naome quality check --changed --json` emits `repository-model-stale` as a
+  changed-code finding.
+
+The fix is explicit and idempotent:
+
+```text
+naome repo model --write --json
+```

package/templates/naome-root/docs/naome/repository-quality.md

@@ -6,7 +6,17 @@ NAOME keeps legacy debt visible without blocking unrelated feature work.
 
 - `naome quality check --changed` blocks only on files changed in the current
   diff. If a legacy file is touched, that file must satisfy the configured
-  quality rules before commit.
+  quality and semantic changed rules before commit.
+- `naome quality check --path <path>` is the early touched-file gate. Run it
+  immediately after editing a file to catch file length, diff growth, function
+  length, top-level symbol count, same-file duplicate regions, structure
+  issues, and stale adapter/model policy before a large task accumulates.
+  Repeat `--path` for a small touched set. This is a fast local feedback gate;
+  the final `--changed` gate still remains required.
+- `naome semantic check --changed` is also exposed as the explicit semantic
+  changed gate. Fresh verification profiles require it next to
+  `repository-quality-check`; `quality check --changed` includes the same
+  semantic changed findings for backward compatibility with older profiles.
 - `naome quality report` scans the repository with normal budgets and reports
   debt without failing feature work. Full repository duplicate,
   near-duplicate, and semantic grouping checks are deep-only.
@@ -33,12 +43,41 @@ Adapters are plug-and-play profiles such as `rust` or
 path rules at runtime without hard-coding a specific product repository into
 the generic template.
 
+Repository stacks can change after setup. `quality check --changed` and
+`quality report` compare current repository signals with committed
+`enabledAdapters`; when a new stack is present but not enabled, they emit
+`adapter-policy-stale`. Use `naome quality reconcile --json` to inspect the
+delta and `naome quality reconcile --write` to update
+`.naome/repository-quality.json` and `.naome/repository-structure.json`
+deterministically. Do not hand-edit adapter lists as the normal path.
+
+Built-in adapter detection is path/manifest based and deterministic:
+
+- `rust`: `Cargo.toml` or `.rs` files.
+- `javascript-typescript`: `package.json` or JS/TS files.
+- `swift`: `Package.swift` or `.swift` files.
+- `xcode`: `.xcodeproj` or `.xcworkspace` content.
+- `xctest`: Swift test targets such as `Tests`, `*Tests`, or `*UITests`.
+- `swiftui`: SwiftUI-style app/view paths such as `*App.swift`,
+  `*View.swift`, `Views`, or Preview Content.
+- `ios-app-structure`: iOS app entrypoints, `Info.plist`, entitlements, or
+  asset catalogs.
+- `swift-package`: Swift Package Manager `Sources` and `Tests` layout.
+- `ios-resources`: `.xcassets`, `.strings`, `.plist`, `.storyboard`, `.xib`,
+  and entitlements.
+- `generated-ios`: SwiftGen, Sourcery, protobuf, and `*.generated.swift`
+  outputs.
+
 Local `pathRules` are project overrides, not product defaults. They may document
 repo-specific debt or special file roles, but loosening a rule to pass a feature
 diff requires human review.
 
 The scanner has three modes:
 
+- `PathScoped`: explicitly requested touched files are read fully, with the
+  repository path index used for path/structure context. It avoids fully
+  analyzing unrelated changed files, making it suitable directly after file
+  writes.
 - `ChangedFast`: changed files are read fully; unchanged files may contribute
   cached facts for duplicate comparison.
 - `Report`: repository-wide, budgeted debt visibility. If budgets are hit, JSON
@@ -64,29 +103,30 @@ path roles, module/layer policy, adapters, and cleanup routing.
 Agents may propose stricter repo-specific rules after inspecting the language
 and stack.
 
-## Planned Semantic Cleanup
+## Semantic Cleanup
 
 Some maintainability debt is semantic rather than purely syntactic. Examples
 include inline legacy compatibility fixtures, copied config objects, stale test
 builders, hand-written schema snapshots, and helper data that should move into a
 shared factory after enough call sites accumulate.
 
-NAOME should detect these with a generic semantic-cleanup layer instead of
-hard-coding product paths or deleting compatibility fixtures opportunistically.
-The planned model is:
+NAOME detects these with a generic semantic-cleanup layer instead of hard-coding
+product paths or deleting compatibility fixtures opportunistically. The model
+is:
 
 - detect repeated object shapes, schema literals, fixture builders, and config
   snapshots across changed and report-mode files;
 - classify each finding as `legacy fixture`, `duplicated fixture`,
   `schema snapshot`, `generated metadata`, or `inline builder`;
 - keep existing report-mode debt visible without blocking unrelated work;
-- block only changed/new semantic debt unless local policy marks it report-only;
+- block changed/new semantic debt through `quality check --changed` and
+  `semantic check --changed`;
 - route cleanup to extract a shared fixture, builder, schema writer, or generated
   metadata refresh command;
 - preserve behavior by requiring tests before removing or consolidating legacy
   compatibility fixtures.
 
-The first implementation exposes this as a scout, not an auto-fixer:
+Semantic cleanup is a scout and gate, not an auto-fixer:
 
 - `naome semantic report --json` runs a budgeted semantic report.
 - `naome semantic report --deep --json` runs repo-wide semantic grouping.

package/templates/naome-root/docs/naome/repository-structure.md

@@ -36,9 +36,16 @@ module location is more appropriate.
 ## Adapters
 
 The core is language-independent. Adapters add deterministic signals for stack
-conventions. Built-in adapters currently include `rust` and
-`javascript-typescript`; future adapters can add source roots, test roots,
-module roots, and allowed root files without changing gate behavior.
+conventions. Built-in adapters currently include `rust`,
+`javascript-typescript`, `swift`, `xcode`, `xctest`, `swiftui`,
+`ios-app-structure`, `swift-package`, `ios-resources`, and `generated-ios`.
+Future adapters can add source roots, test roots, module roots, and allowed
+root files without changing gate behavior.
+
+If the repository later adds a new stack, `quality check --changed` and
+`quality report` emit `adapter-policy-stale` until
+`naome quality reconcile --write` updates the committed quality and structure
+policy files.
 
 ## Local Policy
 

package/templates/naome-root/docs/naome/task-ledger.md

@@ -0,0 +1,71 @@
+# Task Ledger
+
+NAOME task state is moving from one mutable aggregate file to a canonical task
+ledger. The compatibility file `.naome/task-state.json` remains supported, but
+new deterministic task tooling can use `.naome/tasks/` as the source of truth.
+
+## Layout
+
+```text
+.naome/tasks/
+  active.json
+  <task-id>/
+    task.json
+    events.jsonl
+    mutations.json
+    proofs/
+      <check-id>.json
+```
+
+- `active.json` identifies the primary task and leaves room for future
+  worklanes.
+- `task.json` contains the stable task contract: request, prompt, admission,
+  allowed paths, change types, required checks, and human-review policy.
+- `events.jsonl` is append-only. Status changes, blockers, and later decisions
+  are added as events instead of rewriting the whole task.
+- `mutations.json` records touched paths and mutation ownership.
+- `proofs/<check-id>.json` stores one verification result per check so parallel
+  checks do not rewrite the same file.
+
+## Compatibility
+
+Existing `naome.task-state.v1` and `naome.task-state.v2` files remain valid. If
+`.naome/tasks/active.json` exists, NAOME readers build a canonical task model
+from the ledger and render a `naome.task-state.v2` projection. If no ledger is
+present, readers fall back to `.naome/task-state.json`.
+
+Use this command when an external tool needs the compatibility file refreshed:
+
+```text
+node .naome/bin/naome.js task render-state --write --json
+```
+
+`naome sync` automatically splits an active legacy `task-state` file into the
+ledger layout. The explicit command remains available for repair or tests:
+
+```text
+node .naome/bin/naome.js task migrate-ledger --write --json
+```
+
+After `.naome/tasks/active.json` exists, `.naome/task-state.json` is a rendered
+compatibility projection. NAOME gates reject a stale projection and report the
+render command instead of accepting hand-edited aggregate state.
+
+## Conflict Policy
+
+`.naome/tasks/` is NAOME control state. It is not task feature scope and is not
+required as proof evidence. Gates ignore ledger control files when checking
+whether product changes stay inside `allowedPaths`.
+
+The intended long-term model is:
+
+```text
+task spec + events + mutations + proofs + verification config
+=> canonical task model
+=> generated task-state projection
+=> gates / route / commit / completion
+```
+
+This keeps old repositories backward-compatible while making future parallel
+agents safer: separate agents and checks can write separate event/proof files
+instead of all competing for `.naome/task-state.json`.

package/templates/naome-root/docs/naome/testing.md

@@ -9,6 +9,18 @@ Status: Uninitialized
 | NAOME baseline | Built-in harness proof | See Known Checks | Seeded by installer; extend during first-run intake. |
 | Repository-specific work | Unknown | Unknown | Fill during first-run intake. |
 
+## Early Feedback
+
+After writing or heavily editing a file, run
+`node .naome/bin/naome.js quality check --path <path>` for immediate
+touched-file feedback. This catches local size, symbol, duplicate, structure,
+and stale-policy issues before the task grows. It does not replace the final
+`repository-quality-check`; always run the changed-file gate before completion.
+
+Optional Codex hooks can provide the same kind of early feedback during an
+agent run. They are acceleration only; final proof still comes from the
+commands in this document and `.naome/verification.json`.
+
 ## Known Checks
 
 | Check id | Command | Cwd | Cost | Last verified |
@@ -17,6 +29,7 @@ Status: Uninitialized
 | naome-harness-health | `node .naome/bin/check-harness-health.js` | `.` | fast | null |
 | naome-task-state | `node .naome/bin/check-task-state.js` | `.` | fast | null |
 | repository-quality-check | `node .naome/bin/naome.js quality check --changed` | `.` | fast | null |
+| repository-semantic-check | `node .naome/bin/naome.js semantic check --changed` | `.` | fast | null |
 
 ## Verification Phases
 
@@ -57,8 +70,8 @@ phase is failing or missing.
   and 10 release gates.
 - Store long command output as a compact summary that preserves command, cwd,
   exit code, relevant lines, affected paths, and artifacts.
-- When intake defines change types, include `repository-quality-check` as a
-  required check for source, structure, documentation, harness, template, and
-  CI changes.
+- When intake defines change types, include `repository-quality-check` and
+  `repository-semantic-check` as required checks for source, structure,
+  documentation, harness, template, and CI changes.
 - Before completion, select proof from the Verification Map when possible.
 - Report exact commands and results. Do not claim proof that did not run.