@t275005746/gse 0.1.0 → 0.1.2

package/references/drift-audit.md

@@ -1,81 +1,82 @@
-# Drift Audit
-
-Use this when project reality may have diverged from `.gse/`, project docs, generated scaffolds, host adapters, tool assumptions, model routing, or recorded evidence.
-
-Drift audit keeps long-running agent work from following stale instructions. It is a focused consistency check, not a broad rewrite.
-
-## Trigger Conditions
-
-Run a drift audit when any of these are true:
-
-- A command fails because package manager, runtime, service port, CI, browser, MCP, LSP, model, or host capability assumptions were stale.
-- The user says a tool, standard, permission, or host capability exists but GSE cannot see it.
-- `.gse/project-profile.md`, `.gse/tooling.md`, `.gse/goal-map.md`, `.gse/quality-gates.md`, or evidence records disagree with current project files.
-- Generated scaffolds or host adapters were copied earlier and may no longer point to `.gse/` as the source of truth.
-- A model/provider/tool route was previously documented but not recently verified.
-- Release, recovery, incident, or repeated failure evidence suggests stale rules or stale assumptions.
-- A future agent would likely choose the wrong workflow because old docs are more visible than current facts.
-
-Do not run a broad drift audit for a tiny local edit unless the edit exposes stale project facts.
-
-## Drift Categories
-
-| Category | Examples | Default remediation |
-|---|---|---|
-| stale docs | README, AGENTS.md, architecture docs, ADRs, comments, old handoffs | Update or mark outdated; link to current source of truth |
-| stale generated scaffolds | `.gse/` templates, copied host folders, generated commands, stale examples | Regenerate or patch the smallest affected artifact |
-| stale host adapters | `.codex/`, `.claude/`, `.agents/`, MCP, hooks, subagent notes, runtime bridges | Point back to `.gse/`; update verified/unknown capability status |
-| stale tool assumptions | package manager, scripts, ports, CI, browser, LSP, MCP, deployment, observability | Re-read project config; mark verified, documented, unknown, or unavailable |
-| stale model assumptions | provider/model ids, capability fit, cost, latency, privacy, fallback, hosted tools | Reclassify with model-routing evidence; avoid claiming support without proof |
-| stale project profile facts | identity, commands, standards, release rules, permissions, known gotchas | Refresh `.gse/project-profile.md` from current files only |
-| stale evidence or goal-map state | completed work not reflected, obsolete next action, old risk still listed, missing residual risk | Update `.gse/evidence/`, `.gse/goal-map.md`, or `.gse/current-slice.md` concisely |
-
-## Minimum Audit Record
-
-Use this format in evidence logs or handoff notes:
-
-```text
-Drift scope:
-Drift category:
-Current source checked:
-Stale or conflicting record:
-Finding:
-Remediation:
-Evidence:
-Follow-up slices:
-```
-
-Findings must come from current files, command output, local tool help, trusted project docs, or focused experiments. If the evidence is indirect, record a risk instead of a finding.
-
-## Evidence Requirements
-
-A drift audit should prove at least one of these:
-
-- The recorded assumption still matches current project reality.
-- The recorded assumption is stale and has been corrected or marked outdated.
-- The current evidence is insufficient, so the status is `unknown` or a follow-up slice is required.
-- The project has conflicting sources of truth and an owner decision is needed.
-
-Use `verified`, `documented`, `unknown`, and `unavailable` consistently with references/tool-adapters.md. Do not promote `documented` or `unknown` to `verified` without current evidence.
-
-## Remediation Paths
-
-Choose the smallest durable remediation:
-
-- Refresh `.gse/project-profile.md` when project commands, tools, standards, permissions, release rules, or known gotchas changed.
-- Refresh `.gse/goal-map.md` or `.gse/current-slice.md` when next action, risks, or landed evidence are stale.
-- Refresh host adapter notes when host-specific folders duplicate policy or claim unavailable capabilities.
-- Refresh tool/model routing notes when provider, model, MCP, LSP, browser, CI, or deployment assumptions changed.
-- Add a learning entry only when the drift pattern is reusable beyond the current slice.
+# Drift Audit
+
+Use this when project reality may have diverged from `.gse/`, project docs, generated scaffolds, host adapters, tool assumptions, model routing, or recorded evidence.
+
+Drift audit keeps long-running agent work from following stale instructions. It is a focused consistency check, not a broad rewrite.
+
+## Trigger Conditions
+
+Run a drift audit when any of these are true:
+
+- A command fails because package manager, runtime, service port, CI, browser, MCP, LSP, model, or host capability assumptions were stale.
+- The user says a tool, standard, permission, or host capability exists but GSE cannot see it.
+- `.gse/project-profile.md`, `.gse/tooling.md`, `.gse/goal-map.md`, `.gse/quality-gates.md`, or evidence records disagree with current project files.
+- Generated scaffolds or host adapters were copied earlier and may no longer point to `.gse/` as the source of truth.
+- A model/provider/tool route was previously documented but not recently verified.
+- Release, recovery, incident, or repeated failure evidence suggests stale rules or stale assumptions.
+- A future agent would likely choose the wrong workflow because old docs are more visible than current facts.
+
+Do not run a broad drift audit for a tiny local edit unless the edit exposes stale project facts.
+
+## Drift Categories
+
+| Category | Examples | Default remediation |
+|---|---|---|
+| stale docs | README, AGENTS.md, architecture docs, ADRs, comments, old handoffs | Update or mark outdated; link to current source of truth |
+| stale generated scaffolds | `.gse/` templates, copied host folders, generated commands, stale examples | Regenerate or patch the smallest affected artifact |
+| stale host adapters | `.codex/`, `.claude/`, `.agents/`, MCP, hooks, subagent notes, runtime bridges | Point back to `.gse/`; update verified/unknown capability status |
+| stale tool assumptions | package manager, scripts, ports, CI, browser, LSP, MCP, deployment, observability | Re-read project config; mark verified, documented, unknown, or unavailable |
+| stale model assumptions | provider/model ids, capability fit, cost, latency, privacy, fallback, hosted tools | Reclassify with model-routing evidence; avoid claiming support without proof |
+| stale project profile facts | identity, commands, standards, release rules, permissions, known gotchas | Refresh `.gse/project-profile.md` from current files only |
+| stale evidence or goal-map state | completed work not reflected, obsolete next action, old risk still listed, missing residual risk | Update `.gse/evidence/`, `.gse/goal-map.md`, or `.gse/current-slice.md` concisely |
+
+## Minimum Audit Record
+
+Use this format in evidence logs or handoff notes:
+
+```text
+Drift scope:
+Drift category:
+Current source checked:
+Stale or conflicting record:
+Finding:
+Remediation:
+Evidence:
+Follow-up slices:
+```
+
+Findings must come from current files, command output, local tool help, trusted project docs, or focused experiments. If the evidence is indirect, record a risk instead of a finding.
+
+## Evidence Requirements
+
+A drift audit should prove at least one of these:
+
+- The recorded assumption still matches current project reality.
+- The recorded assumption is stale and has been corrected or marked outdated.
+- The current evidence is insufficient, so the status is `unknown` or a follow-up slice is required.
+- The project has conflicting sources of truth and an owner decision is needed.
+
+Use `verified`, `documented`, `unknown`, and `unavailable` consistently with references/tool-adapters.md. Do not promote `documented` or `unknown` to `verified` without current evidence.
+
+## Remediation Paths
+
+Choose the smallest durable remediation:
+
+- Refresh `.gse/project-profile.md` when project commands, tools, standards, permissions, release rules, or known gotchas changed.
+- Refresh `.gse/goal-map.md` or `.gse/current-slice.md` when next action, risks, or landed evidence are stale.
+- Refresh host adapter notes when host-specific folders duplicate policy or claim unavailable capabilities.
+- Refresh tool/model routing notes when provider, model, MCP, LSP, browser, CI, or deployment assumptions changed.
+- Add a learning entry only when the drift pattern is reusable beyond the current slice.
 - Add or update a script/template/gate when the same drift appears repeatedly.
-
-Never update stale docs by inventing support. Prefer `unknown` plus a focused verification action.
-
-## Integration
-
-- Use references/project-profile.md when drift affects project-specific standards, commands, tools, permissions, release rules, or known gotchas.
-- Use references/host-adapters.md when drift affects Codex, Claude Code, Hermes/AION-style runtime, WorkBuddy, MCP, hooks, skills, subagents, or host-specific folders.
-- Use references/tool-adapters.md when drift affects tool status, LSP/index, browser, CI, MCP, package manager, or command assumptions.
-- Use references/model-routing.md when drift affects provider/model capability, cost, latency, privacy, fallback, or hosted tool behavior.
-- Use references/learning-system.md when a drift pattern should be promoted into a lesson, checklist, gate, script, or skill update.
-- Use references/recovery.md when drift is discovered during interrupted, failed, or handed-off work.
+- Run `scripts/audit-learning-drift.mjs --root <gse-skill> --target <project-root> --json` when `.gse/learning-promotions.md` or `/gse continue` shows promoted learning candidates. The audit surfaces candidates that are documented but not yet covered by a guard, quality gate, continue/close check, or focused script.
+
+Never update stale docs by inventing support. Prefer `unknown` plus a focused verification action.
+
+## Integration
+
+- Use references/project-profile.md when drift affects project-specific standards, commands, tools, permissions, release rules, or known gotchas.
+- Use references/host-adapters.md when drift affects Codex, Claude Code, Hermes/AION-style runtime, WorkBuddy, MCP, hooks, skills, subagents, or host-specific folders.
+- Use references/tool-adapters.md when drift affects tool status, LSP/index, browser, CI, MCP, package manager, or command assumptions.
+- Use references/model-routing.md when drift affects provider/model capability, cost, latency, privacy, fallback, or hosted tool behavior.
+- Use references/learning-system.md when a drift pattern should be promoted into a lesson, checklist, gate, script, or skill update.
+- Use references/recovery.md when drift is discovered during interrupted, failed, or handed-off work.

package/references/evidence-taxonomy.md

@@ -1,123 +1,160 @@
-# Evidence Taxonomy
-
-Use this to decide whether work is only produced, actually verified, or accepted.
-
+# Evidence Taxonomy
+
+Use this to decide whether work is only produced, actually verified, or accepted.
+
 GSE uses three evidence gates:
-
-```text
-result -> verified -> accepted
-```
-
+
+```text
+result -> verified -> accepted
+```
+
 Do not skip gates. Do not claim a higher gate when the evidence only proves a lower gate.
 
-## Gate 1: Result
-
-`result` means the requested artifact or change exists.
-
-Enough evidence:
-
-- File, script, template, reference, commit, report, screenshot, or generated output exists.
-- The change is scoped to the requested slice.
-- The agent can point to the exact path or output.
-
-Not enough for `result`:
-
-- A plan to create the artifact.
-- A final answer describing what would be changed.
-- A command that was intended to write a file but did not confirm the file exists.
-
-Example:
-
-- `scripts/audit-gse.mjs` exists: result.
-- `.gse/project-profile.md` was written in a temp fixture: result.
-
-## Gate 2: Verified
-
-`verified` means the result was checked against acceptance criteria with evidence appropriate to the risk.
-
-Enough evidence:
-
-- Focused test, smoke, structure check, build, typecheck, lint, browser check, API check, or manual inspection directly covers the acceptance criteria.
-- The command output or inspected artifact proves the expected behavior.
-- Known residual risk is recorded.
-
-Not enough for `verified`:
-
-- The file exists but was not inspected.
-- A broad test passed but does not cover the changed behavior.
-- A command ran without checking the relevant output.
-- A tool is merely configured or documented but not run.
-- The agent says it looks right without evidence.
-
-Example:
+## Evidence Status vs Evidence Level
 
-- `audit-gse.mjs` reports `GSE-C04` as `strong (2/2, score 1)` after adding `router.md`: verified for the router structural criterion.
-- A project profile lists Playwright as `documented` because config exists: not verified tool availability.
+Evidence status answers whether the work is result, verified, or accepted.
 
-## Gate 3: Accepted
+Evidence level answers what kind of proof produced that status.
 
-`accepted` means the verified result has been accepted by the required authority.
+Keep both dimensions visible for non-trivial work:
 
-Enough evidence:
-
-- The user explicitly accepts the result.
-- A required reviewer or gate approves it.
-- A release, archive, or project process marks it accepted.
-- A pre-defined acceptance policy says verified evidence is sufficient for this task level.
-
-Not enough for `accepted`:
-
-- The agent is satisfied.
-- The result passed a local smoke but no acceptance policy says that is enough.
-- The user has not reviewed a user-facing, policy, release, or irreversible change when review is required.
-
-Example:
-
-- A focused smoke passes for an internal script: can be accepted by policy if the task is Lite or Standard and no human approval is required.
-- A release plan or public workflow change usually needs explicit human acceptance or release-gate acceptance.
-
-## Required Evidence Record
+```text
+status: result | verified | accepted | blocked | not ready
+evidenceLevel: result | verified-unit | verified-component | verified-api | verified-browser | verified-ci | accepted-owner | accepted-release | external-required
+requiredEvidenceLevel: optional expected level for the claim
+```
 
+Use the narrowest honest level:
+
+| Evidence level | Meaning | Typical proof |
+|---|---|---|
+| `result` | Artifact exists or command produced an output, but behavior is not verified. | file exists, generated report, dry-run output |
+| `verified-unit` | Unit or script-level behavior is verified. | focused unit test, parser test, structure audit |
+| `verified-component` | Component-level or local integration behavior is verified without a real browser/runtime path. | component test, fixture integration, store/API mock |
+| `verified-api` | API/state contract is verified through an API, route, database, or state-machine check. | API smoke, state contract test, persistence fixture |
+| `verified-browser` | User-visible browser behavior is verified in a real browser automation or equivalent rendered UI smoke. | Playwright/browser smoke, screenshot-backed UI check |
+| `verified-ci` | CI or release pipeline executed and passed in the target environment. | public CI run, release workflow run, build pipeline evidence |
+| `accepted-owner` | Owner/reviewer accepts a verified result. | explicit owner acceptance, review approval, accepted project record |
+| `accepted-release` | Release/publication gate accepts the verified result. | release record, package publication record, marketplace approval |
+| `external-required` | Required evidence depends on an external owner, host, marketplace, registry, or runtime not available in the current local run. | native slash-command host proof, marketplace approval, public release gate |
+
+Examples:
+
+- A UI component test can be `status: verified` with `evidenceLevel: verified-component`, but it must not be described as browser proof.
+- A Playwright smoke can be `status: verified` with `evidenceLevel: verified-browser`.
+- A public CI record can be `status: verified` or `accepted` with `evidenceLevel: verified-ci`, depending on the project acceptance policy.
+- A pending native slash-command claim should stay `evidenceLevel: external-required` until a real host invocation record exists.
+
+## Gate 1: Result
+
+`result` means the requested artifact or change exists.
+
+Enough evidence:
+
+- File, script, template, reference, commit, report, screenshot, or generated output exists.
+- The change is scoped to the requested slice.
+- The agent can point to the exact path or output.
+
+Not enough for `result`:
+
+- A plan to create the artifact.
+- A final answer describing what would be changed.
+- A command that was intended to write a file but did not confirm the file exists.
+
+Example:
+
+- `scripts/audit-gse.mjs` exists: result.
+- `.gse/project-profile.md` was written in a temp fixture: result.
+
+## Gate 2: Verified
+
+`verified` means the result was checked against acceptance criteria with evidence appropriate to the risk.
+
+Enough evidence:
+
+- Focused test, smoke, structure check, build, typecheck, lint, browser check, API check, or manual inspection directly covers the acceptance criteria.
+- The command output or inspected artifact proves the expected behavior.
+- Known residual risk is recorded.
+
+Not enough for `verified`:
+
+- The file exists but was not inspected.
+- A broad test passed but does not cover the changed behavior.
+- A command ran without checking the relevant output.
+- A tool is merely configured or documented but not run.
+- The agent says it looks right without evidence.
+
+Example:
+
+- `audit-gse.mjs` reports `GSE-C04` as `strong (2/2, score 1)` after adding `router.md`: verified for the router structural criterion.
+- A project profile lists Playwright as `documented` because config exists: not verified tool availability.
+
+## Gate 3: Accepted
+
+`accepted` means the verified result has been accepted by the required authority.
+
+Enough evidence:
+
+- The user explicitly accepts the result.
+- A required reviewer or gate approves it.
+- A release, archive, or project process marks it accepted.
+- A pre-defined acceptance policy says verified evidence is sufficient for this task level.
+
+Not enough for `accepted`:
+
+- The agent is satisfied.
+- The result passed a local smoke but no acceptance policy says that is enough.
+- The user has not reviewed a user-facing, policy, release, or irreversible change when review is required.
+
+Example:
+
+- A focused smoke passes for an internal script: can be accepted by policy if the task is Lite or Standard and no human approval is required.
+- A release plan or public workflow change usually needs explicit human acceptance or release-gate acceptance.
+
+## Required Evidence Record
+
 Every non-trivial GSE slice should record:
-
-```text
-Outcome:
-Scope:
-Acceptance:
+
+```text
+Outcome:
+Scope:
+Acceptance:
 Result evidence:
 Verification evidence:
+Evidence level:
+Required evidence level:
 Accepted by:
 Residual risk:
 Next action:
 ```
-
-Use `accepted by: policy` only when the applicable policy is named, such as `Lite focused smoke policy`.
-
-For project-local GSE updates, scaffold changes, host adapter changes, and release-readiness work, use `assets/templates/update-release-acceptance-record.md` so local decisions preserved, changed files, rollback notes, owner gate, accepted-by status, residual risks, and next action are not lost.
-
-## Status Rules
-
-- `planned`: desired but no result yet.
-- `result`: artifact/change exists but has not been verified.
-- `verified`: acceptance criteria are directly covered by evidence.
-- `accepted`: verified result has user, reviewer, release, archive, or policy acceptance.
-- `blocked`: meaningful progress cannot continue and the blocker satisfies the project's blocked rule.
-
-## Tool Status Is Separate
-
-Do not confuse evidence gates with tool availability status.
-
-- `documented`: a file says a tool or command exists.
-- `verified`: the tool or command was actually run or checked.
-- `unknown`: no trustworthy evidence yet.
-- `unavailable`: expected tool is missing or failing.
-
-These tool statuses can support the evidence taxonomy, but they do not replace result/verified/accepted gates.
-
-## Common Mistakes
-
-- Treating generated files as verified behavior.
-- Treating config presence as a working tool.
-- Treating a broad green test as evidence for a narrow change without coverage proof.
-- Treating an internal smoke as user acceptance for visible product behavior.
-- Updating goal status to complete when the evidence only proves one slice.
+
+Use `accepted by: policy` only when the applicable policy is named, such as `Lite focused smoke policy`.
+
+For project-local GSE updates, scaffold changes, host adapter changes, and release-readiness work, use `assets/templates/update-release-acceptance-record.md` so local decisions preserved, changed files, rollback notes, owner gate, accepted-by status, residual risks, and next action are not lost.
+
+## Status Rules
+
+- `planned`: desired but no result yet.
+- `result`: artifact/change exists but has not been verified.
+- `verified`: acceptance criteria are directly covered by evidence.
+- `accepted`: verified result has user, reviewer, release, archive, or policy acceptance.
+- `blocked`: meaningful progress cannot continue and the blocker satisfies the project's blocked rule.
+
+## Tool Status Is Separate
+
+Do not confuse evidence gates with tool availability status.
+
+- `documented`: a file says a tool or command exists.
+- `verified`: the tool or command was actually run or checked.
+- `unknown`: no trustworthy evidence yet.
+- `unavailable`: expected tool is missing or failing.
+
+These tool statuses can support the evidence taxonomy, but they do not replace result/verified/accepted gates.
+
+## Common Mistakes
+
+- Treating generated files as verified behavior.
+- Treating config presence as a working tool.
+- Treating a broad green test as evidence for a narrow change without coverage proof.
+- Treating an internal smoke as user acceptance for visible product behavior.
+- Updating goal status to complete when the evidence only proves one slice.

package/references/file-ownership.md

@@ -1,96 +1,98 @@
-# File Ownership And Dirty Worktree
-
-Use this when GSE work touches files in a dirty worktree, uses real subagents, simulates roles sequentially, or coordinates multiple agents, branches, worktrees, or review loops.
-
-## Core Rule
-
-Protect user work first. Then protect agent work from other agent work.
-
-A file is not safe to edit just because it is in scope. First inspect whether it already has unrelated changes, generated output, local-only edits, or another active owner.
-
-## Ownership Levels
-
-| Level | Use when | Required action |
-|---|---|---|
-| Observe | Read-only location, review, QA, code search | Do not write. Report files inspected if useful. |
-| Soft claim | One agent edits a small bounded slice | State intended files before editing and keep diff scoped. |
-| Explicit claim | Multi-agent work, broad refactor, dirty worktree, shared files | Record owner, allowed files, forbidden files, and release condition. |
-| Isolated worktree | Parallel implementation, risky experiment, long-running branch | Use a separate branch/worktree when the project supports git. |
-
-Level 1 and 2 tasks should not require formal lock files. Escalate only when collision risk is real.
-
-## Dirty Worktree Policy
-
-Before editing implementation or shared docs:
-
-1. Check project status with the safest available command, usually `git status --short` when the directory is a git repo.
-2. If the directory is not a git repo, state that git ownership evidence is unavailable and rely on file scope plus timestamps/diff if available.
-3. Identify files already modified before your work.
-4. Treat pre-existing changes as user or another agent changes unless evidence proves otherwise.
-5. Do not revert, overwrite, format, move, or delete unrelated changes.
-6. If the target file is already dirty, inspect it and merge around existing changes. Ask only if the existing change makes the requested edit ambiguous or unsafe.
-7. After editing, verify the final changed-file set matches the slice.
-
-## Claim Format
-
-Use this lightweight claim in dispatch packets, slice notes, or comments when explicit ownership is needed:
-
-For delegated or role-separated work, prefer `assets/templates/dispatch-packet.md` so the claim also includes objective, context, expected output, verification, and stop conditions.
-
-```text
-Owner:
-Purpose:
-Allowed files:
-Forbidden files:
-Expected edits:
-Verification:
-Release condition:
-```
-
-Claims should be short and local to the task. Do not create permanent process artifacts for one-off edits unless the project already requires them.
-
-## Subagent And Role Rules
-
-When real subagent tools exist:
-
+# File Ownership And Dirty Worktree
+
+Use this when GSE work touches files in a dirty worktree, uses real subagents, simulates roles sequentially, or coordinates multiple agents, branches, worktrees, or review loops.
+
+## Core Rule
+
+Protect user work first. Then protect agent work from other agent work.
+
+A file is not safe to edit just because it is in scope. First inspect whether it already has unrelated changes, generated output, local-only edits, or another active owner.
+
+## Ownership Levels
+
+| Level | Use when | Required action |
+|---|---|---|
+| Observe | Read-only location, review, QA, code search | Do not write. Report files inspected if useful. |
+| Soft claim | One agent edits a small bounded slice | State intended files before editing and keep diff scoped. |
+| Explicit claim | Multi-agent work, broad refactor, dirty worktree, shared files | Record owner, allowed files, forbidden files, and release condition. |
+| Isolated worktree | Parallel implementation, risky experiment, long-running branch | Use a separate branch/worktree when the project supports git. |
+
+Level 1 and 2 tasks should not require formal lock files. Escalate only when collision risk is real.
+
+## Dirty Worktree Policy
+
+Before editing implementation or shared docs:
+
+1. Check project status with the safest available command, usually `git status --short` when the directory is a git repo.
+2. If the directory is not a git repo, state that git ownership evidence is unavailable and rely on file scope plus timestamps/diff if available.
+3. Identify files already modified before your work.
+4. Treat pre-existing changes as user or another agent changes unless evidence proves otherwise.
+5. Do not revert, overwrite, format, move, or delete unrelated changes.
+6. If the target file is already dirty, inspect it and merge around existing changes. Ask only if the existing change makes the requested edit ambiguous or unsafe.
+7. After editing, verify the final changed-file set matches the slice.
+
+## Claim Format
+
+Use this lightweight claim in dispatch packets, slice notes, or comments when explicit ownership is needed:
+
+For delegated or role-separated work, prefer `assets/templates/dispatch-packet.md` so the claim also includes objective, context, expected output, verification, and stop conditions.
+
+```text
+Owner:
+Purpose:
+Allowed files:
+Forbidden files:
+Expected edits:
+Verification:
+Release condition:
+```
+
+Claims should be short and local to the task. Do not create permanent process artifacts for one-off edits unless the project already requires them.
+
+## Subagent And Role Rules
+
+When real subagent tools exist:
+
 - Give each subagent a role, objective, allowed files, forbidden files, and expected output.
 - Prefer read-only locator/reviewer/QA roles for broad exploration.
-- Do not dispatch parallel builders to the same files or tightly coupled modules.
-- Require implementers to report files changed and verification run.
-- Run spec review before code-quality review when both exist.
-- Coordinator owns final integration and evidence.
-
-When no real subagent tool exists:
-
+- Keep release roles focused on release/public/owner/external claim boundaries unless they are explicitly assigned release-file edits.
+- Do not dispatch parallel builders to the same files or tightly coupled modules.
+- Require implementers to report files changed and verification run.
+- Run spec review before code-quality review when both exist.
+- Coordinator owns final integration and evidence.
+
+When no real subagent tool exists:
+
 - Execute roles sequentially in the main session.
 - Say that no real subagent dispatch occurred if the distinction matters.
 - Keep the same ownership boundaries: locator is read-only, builder writes assigned files, reviewer is read-only, QA writes evidence only.
+- Verifier records commands and evidence level; release records claim boundaries and external gates.
 - Do not fake parallelism, independent review, or subagent status.
-
-## Shared File Rules
-
-Shared files include routing docs, config, package manifests, migration files, generated clients, lockfiles, schemas, shared types, and design-system primitives.
-
-For shared files:
-
-- Read surrounding patterns before editing.
-- Avoid formatting churn.
-- Keep behavior and formatting changes separate when feasible.
-- Check for generated-file policy before editing generated outputs.
-- If multiple slices need the same shared file, serialize edits through the coordinator.
-
-## Ownership Conflicts
-
-If two tasks need the same file:
-
-1. Prefer sequencing over parallel edits.
-2. If both are small and related, merge into one slice.
-3. If they are independent but touch the same file, split by branch/worktree or pick one owner.
-4. If an unexpected dirty change appears, stop destructive actions, inspect the diff, and continue only if the merge path is clear.
-5. Record unresolved conflict as a risk or blocker, not as completed work.
-
-## Verification Checklist
-
+
+## Shared File Rules
+
+Shared files include routing docs, config, package manifests, migration files, generated clients, lockfiles, schemas, shared types, and design-system primitives.
+
+For shared files:
+
+- Read surrounding patterns before editing.
+- Avoid formatting churn.
+- Keep behavior and formatting changes separate when feasible.
+- Check for generated-file policy before editing generated outputs.
+- If multiple slices need the same shared file, serialize edits through the coordinator.
+
+## Ownership Conflicts
+
+If two tasks need the same file:
+
+1. Prefer sequencing over parallel edits.
+2. If both are small and related, merge into one slice.
+3. If they are independent but touch the same file, split by branch/worktree or pick one owner.
+4. If an unexpected dirty change appears, stop destructive actions, inspect the diff, and continue only if the merge path is clear.
+5. Record unresolved conflict as a risk or blocker, not as completed work.
+
+## Verification Checklist
+
 Before claiming completion:
 
 - Intended files are the only files changed, or every extra file is explained.
@@ -99,9 +101,11 @@ Before claiming completion:
 - Subagent work, if any, has role, allowed files, and verification evidence.
 - The evidence record names focused validation and residual risk.
 
-## Project Integration
-
-- `references/agent-roles.md` defines role responsibilities.
-- `references/operating-model.md` defines when ownership is checked in the execute loop.
-- `references/quality-gates.md` requires dirty-worktree evidence before completion.
-- `.gse/project-profile.md` should record project-specific branching, generated-file, and lockfile rules.
+`scripts/audit-close-gate.mjs` reports staged, unstaged, untracked, mixed, conflict, and common generated/test artifact paths so close reviews do not have to infer ownership from prose.
+
+## Project Integration
+
+- `references/agent-roles.md` defines role responsibilities.
+- `references/operating-model.md` defines when ownership is checked in the execute loop.
+- `references/quality-gates.md` requires dirty-worktree evidence before completion.
+- `.gse/project-profile.md` should record project-specific branching, generated-file, and lockfile rules.