@t275005746/gse 0.1.0 → 0.1.1

package/references/evidence-taxonomy.md

@@ -1,123 +1,123 @@
-# Evidence Taxonomy
-
-Use this to decide whether work is only produced, actually verified, or accepted.
-
-GSE uses three evidence gates:
-
-```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:
-
-- `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:
-Result evidence:
-Verification evidence:
-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.
+# Evidence Taxonomy
+
+Use this to decide whether work is only produced, actually verified, or accepted.
+
+GSE uses three evidence gates:
+
+```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:
+
+- `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:
+Result evidence:
+Verification evidence:
+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.

package/references/file-ownership.md

@@ -1,107 +1,107 @@
-# 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:
-
-- 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.
-- 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
-
-Before claiming completion:
-
-- Intended files are the only files changed, or every extra file is explained.
-- Pre-existing dirty files were not reverted or overwritten.
-- Generated/test/output artifacts are excluded unless the project requires them.
-- 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.
+# 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:
+
+- 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.
+- 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
+
+Before claiming completion:
+
+- Intended files are the only files changed, or every extra file is explained.
+- Pre-existing dirty files were not reverted or overwritten.
+- Generated/test/output artifacts are excluded unless the project requires them.
+- 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.

package/references/final-readiness.md

@@ -1,84 +1,84 @@
-# Final Readiness Matrix
-
-Use this when deciding whether GSE can be called open-source-ready, installable, and cross-host usable.
-
-This matrix is a claim boundary. It separates local verified capability from owner-required or external evidence. Do not collapse these states into a single "done" label.
-
-## Status Vocabulary
-
-- `verified`: GSE has current local evidence from scripts, records, or package/install audits.
-- `owner-required`: the owner must make or approve a decision before the claim can become accepted.
-- `external-required`: a marketplace, public registry, host runtime, security contact, CI, or other external system must provide evidence.
-- `not-claimed`: GSE deliberately does not claim this capability.
-
-## Readiness Areas
-
-The table below describes the baseline/status source for each row. The current truth is computed by `scripts/audit-final-readiness.mjs`; record-driven rows can promote from `owner-required` or `external-required` to `verified` only after accepted evidence records exist.
-
-| Area | Accepted claim requires | Status source / baseline |
-|---|---|---|
-| Skill structure | `SKILL.md`, references, scripts, assets, metadata, and validator pass | verified |
-| Project scaffold | `init-project`, project doctor, state, goal map, evidence index, close gate | verified |
-| Local install | package, install, installed-copy validation, package CLI entrypoint, and installed short CLI status command | verified |
-| npm tarball install | real local npm tarball creation, install into a clean consumer project, installed `gse` bin execution, and installed README audit | verified |
-| npm publish dry-run | npm publish dry-run keeps package identity, CLI bin metadata, required runtime files, and integrity fields without harmful metadata auto-correction | verified |
-| URL install | remote URL install, installed-copy validation, URL-installed short CLI status command, manifest integrity, and tamper rejection | verified |
-| Signing | package signing, verification, signed install, and tamper rejection | verified |
-| Open-source collaboration | README, contributing, security, support, changelog, public release metadata | verified |
-| CI workflow template | public repository workflow file plus local CI-readiness audit | verified |
-| Public CI run record | pending and accepted public CI run record mechanics | verified |
-| Public collaboration templates | issue and PR templates that require outcome, scope, evidence, risk, and claim boundaries | verified |
-| Public repository settings record | pending, verified, and accepted repository settings record mechanics | verified |
-| Public CI run | real public CI run URL or status-check evidence | record-driven external gate |
-| Public repository settings | real repository URL, issue/PR settings, branch protection, required checks, and maintainer acceptance | record-driven external gate |
-| License decision | owner-selected license or explicit not-public decision | record-driven owner gate |
-| Public security contact record | pending and accepted public security contact record mechanics | verified |
-| Public security contact | owner-approved vulnerability disclosure path | record-driven owner gate |
-| Public channel publication record | pending, registry publication, and marketplace approval record mechanics | verified |
-| Public registry publication | real public package or registry publication evidence | record-driven external gate |
-| Marketplace approval | real marketplace/catalog approval or publication evidence | record-driven external gate |
-| Portable command execution | `run-gse-command.mjs` command semantics audit | verified |
-| Host adapters | generated adapter files and compatibility matrix audit | verified |
-| Native slash command | verified host invocation record with native slash support | record-driven external gate |
-| Other host runtime invocation | verified invocation records per host | record-driven external gate |
-
-Do not read the baseline column as live status. For example, once the owner-selected license record is accepted, the audit reports `License decision` as `verified` even though the row remains an owner-gated claim type.
-
-## Audit Command
-
-```text
-node <gse-skill>/scripts/audit-final-readiness.mjs --root <gse-skill>
-```
-
-The audit must report external and owner gates as incomplete unless corresponding records exist. It is valid for the audit to pass while still reporting `owner-required` or `external-required`; passing means the matrix is honest and complete, not that every external gate is satisfied.
-
-Accepted owner/external records promote final rows only when the record contains accepted evidence and the relevant boundary proof. For example, a public CI row requires an accepted public CI run record with a successful conclusion and required-check proof; a registry row requires accepted publication evidence with registry proof; native slash command support requires a host invocation record that proves native slash-command support.
-
-Use the promotion audit to verify that this path still works:
-
-```text
-node <gse-skill>/scripts/audit-final-readiness-promotion.mjs --root <gse-skill>
-```
-
-## Acceptance Packet
-
-When owner-required or external-required rows remain, generate a handoff packet instead of burying follow-up work in prose:
-
-```text
-node <gse-skill>/scripts/generate-final-acceptance-packet.mjs --root <gse-skill> --out <gse-skill>/.gse/acceptance/final-acceptance-packet.md --force
-```
-
-The packet lists the verified local capabilities, every pending owner/external gate, the exact next evidence action, and the anti-overclaim rules. It is a continuation artifact, not acceptance by itself.
-
-## Completion Boundary
-
-GSE can be described as locally verified and release-ready for handoff when the matrix passes and the verified rows have evidence.
-
-GSE can be described as publicly accepted only after:
-
-- owner-selected license or explicit not-public decision is recorded,
-- public security contact policy is approved when public release is intended,
-- public repository settings evidence exists when a public source repository is claimed,
-- public CI run evidence exists when public CI is claimed,
-- registry or marketplace publication evidence exists when those channels are claimed,
-- native slash-command support is recorded per host before it is claimed.
+# Final Readiness Matrix
+
+Use this when deciding whether GSE can be called open-source-ready, installable, and cross-host usable.
+
+This matrix is a claim boundary. It separates local verified capability from owner-required or external evidence. Do not collapse these states into a single "done" label.
+
+## Status Vocabulary
+
+- `verified`: GSE has current local evidence from scripts, records, or package/install audits.
+- `owner-required`: the owner must make or approve a decision before the claim can become accepted.
+- `external-required`: a marketplace, public registry, host runtime, security contact, CI, or other external system must provide evidence.
+- `not-claimed`: GSE deliberately does not claim this capability.
+
+## Readiness Areas
+
+The table below describes the baseline/status source for each row. The current truth is computed by `scripts/audit-final-readiness.mjs`; record-driven rows can promote from `owner-required` or `external-required` to `verified` only after accepted evidence records exist.
+
+| Area | Accepted claim requires | Status source / baseline |
+|---|---|---|
+| Skill structure | `SKILL.md`, references, scripts, assets, metadata, and validator pass | verified |
+| Project scaffold | `init-project`, project doctor, state, goal map, evidence index, close gate | verified |
+| Local install | package, install, installed-copy validation, package CLI entrypoint, and installed short CLI status command | verified |
+| npm tarball install | real local npm tarball creation, install into a clean consumer project, installed `gse` bin execution, and installed README audit | verified |
+| npm publish dry-run | npm publish dry-run keeps package identity, CLI bin metadata, required runtime files, and integrity fields without harmful metadata auto-correction | verified |
+| URL install | remote URL install, installed-copy validation, URL-installed short CLI status command, manifest integrity, and tamper rejection | verified |
+| Signing | package signing, verification, signed install, and tamper rejection | verified |
+| Open-source collaboration | README, contributing, security, support, changelog, public release metadata | verified |
+| CI workflow template | public repository workflow file plus local CI-readiness audit | verified |
+| Public CI run record | pending and accepted public CI run record mechanics | verified |
+| Public collaboration templates | issue and PR templates that require outcome, scope, evidence, risk, and claim boundaries | verified |
+| Public repository settings record | pending, verified, and accepted repository settings record mechanics | verified |
+| Public CI run | real public CI run URL or status-check evidence | record-driven external gate |
+| Public repository settings | real repository URL, issue/PR settings, branch protection, required checks, and maintainer acceptance | record-driven external gate |
+| License decision | owner-selected license or explicit not-public decision | record-driven owner gate |
+| Public security contact record | pending and accepted public security contact record mechanics | verified |
+| Public security contact | owner-approved vulnerability disclosure path | record-driven owner gate |
+| Public channel publication record | pending, registry publication, and marketplace approval record mechanics | verified |
+| Public registry publication | real public package or registry publication evidence | record-driven external gate |
+| Marketplace approval | real marketplace/catalog approval or publication evidence | record-driven external gate |
+| Portable command execution | `run-gse-command.mjs` command semantics audit | verified |
+| Host adapters | generated adapter files and compatibility matrix audit | verified |
+| Native slash command | verified host invocation record with native slash support | record-driven external gate |
+| Other host runtime invocation | verified invocation records per host | record-driven external gate |
+
+Do not read the baseline column as live status. For example, once the owner-selected license record is accepted, the audit reports `License decision` as `verified` even though the row remains an owner-gated claim type.
+
+## Audit Command
+
+```text
+node <gse-skill>/scripts/audit-final-readiness.mjs --root <gse-skill>
+```
+
+The audit must report external and owner gates as incomplete unless corresponding records exist. It is valid for the audit to pass while still reporting `owner-required` or `external-required`; passing means the matrix is honest and complete, not that every external gate is satisfied.
+
+Accepted owner/external records promote final rows only when the record contains accepted evidence and the relevant boundary proof. For example, a public CI row requires an accepted public CI run record with a successful conclusion and required-check proof; a registry row requires accepted publication evidence with registry proof; native slash command support requires a host invocation record that proves native slash-command support.
+
+Use the promotion audit to verify that this path still works:
+
+```text
+node <gse-skill>/scripts/audit-final-readiness-promotion.mjs --root <gse-skill>
+```
+
+## Acceptance Packet
+
+When owner-required or external-required rows remain, generate a handoff packet instead of burying follow-up work in prose:
+
+```text
+node <gse-skill>/scripts/generate-final-acceptance-packet.mjs --root <gse-skill> --out <gse-skill>/.gse/acceptance/final-acceptance-packet.md --force
+```
+
+The packet lists the verified local capabilities, every pending owner/external gate, the exact next evidence action, and the anti-overclaim rules. It is a continuation artifact, not acceptance by itself.
+
+## Completion Boundary
+
+GSE can be described as locally verified and release-ready for handoff when the matrix passes and the verified rows have evidence.
+
+GSE can be described as publicly accepted only after:
+
+- owner-selected license or explicit not-public decision is recorded,
+- public security contact policy is approved when public release is intended,
+- public repository settings evidence exists when a public source repository is claimed,
+- public CI run evidence exists when public CI is claimed,
+- registry or marketplace publication evidence exists when those channels are claimed,
+- native slash-command support is recorded per host before it is claimed.