@t275005746/gse 0.1.0 → 0.1.2

package/references/forward-test.md

@@ -1,133 +1,133 @@
-# Forward Test Protocol
-
-Use this when changing GSE itself, changing reusable project scaffolds, or changing workflow rules that future agents must follow.
-
-Forward testing asks: can a future agent, fresh session, or fixture project use this change without relying on the author's memory?
-
-## Test Levels
-
-| Level | Meaning | Evidence gate | Use when |
-|---|---|---|---|
-| Structural smoke | Files, routing, audit criteria, and key text exist | verified for structure | Small reference/template/script changes |
-| Fixture forward test | A temp project or example repo uses the GSE path end to end | verified for workflow behavior | Bootstrap/profile/templates/adapters change |
-| Fresh-session forward test | A separate agent/session follows GSE with minimal context | accepted candidate | Non-trivial skill behavior, routing, multi-agent, release, recovery, or public-facing workflow changes |
-
-Do not call structural smoke a true forward-test acceptance. It proves the artifact is wired; it does not prove future-agent usability.
-
-## When Required
-
-Forward testing is required for:
-
-- New or changed scripts under `scripts/` that future projects will run.
-- Project scaffold changes under `scripts/init-project.mjs` or `assets/templates/` that affect downstream projects.
-- Router, quality gate, evidence, role, ownership, host adapter, release, recovery, or packaging rules.
-- Any change that claims a GSE capability is accepted rather than merely present or structurally verified.
-
-Forward testing is optional for:
-
-- Narrow wording edits that do not change behavior.
-- Evidence log updates.
-- Internal goal-map/current-slice status updates.
-- Small typo fixes in already tested references.
-
-Forward testing is unnecessary for:
-
-- Purely transient notes.
-- Local-only command output not used as reusable workflow evidence.
-- Work explicitly marked as draft or design judgment.
-
-## Core Scenarios
-
-Pick the smallest scenario that covers the changed behavior.
-
-### Fresh Project Bootstrap
-
-Use when bootstrap, templates, project profile, quality gates, or scaffold layout changes.
-
-Smoke:
-
-1. Create a temp project directory.
-2. Run `node <gse>/scripts/init-project.mjs --target <temp> --mode lite|standard|enterprise` as appropriate.
-3. Verify expected `.gse/` files exist.
-4. Verify rerun safety without `--force` when relevant.
-5. Record generated-file and cleanup policy.
-
-### Existing Repo Adoption
-
-Use when project-profile, discovery, dirty-worktree, tool adapters, or quality gates change.
-
-Smoke:
-
-1. Use a fixture or temp repo with representative files such as `package.json`, `AGENTS.md`, CI config, browser config, and `.env.example`.
-2. Run discovery or manual project-profile steps.
-3. Verify tool statuses stay `documented`, `verified`, `unknown`, or `unavailable` without inventing support.
-4. Verify dirty or pre-existing files are not overwritten.
-
-### Host Adapter Usage
-
-Use when `.codex/`, `.claude/`, `.agents/`, Hermes/AION-style runtime, WorkBuddy, MCP, hook, skill, or plugin adapter rules change.
-
-Smoke:
-
-1. Create or inspect a host adapter note using `assets/templates/host-adapter.md`.
-2. Confirm it points back to `.gse/` as source of truth.
-3. Mark host-specific capabilities with tool status evidence.
-4. Confirm no unsupported subagent, MCP, hook, or browser capability is claimed as verified.
-
-### Subagent Or Role Fallback
-
-Use when agent roles, dispatch packets, ownership, review, or multi-agent rules change.
-
-Smoke:
-
-1. Fill `assets/templates/dispatch-packet.md` for one locator, builder, reviewer, QA, or docs role.
-2. Include role, objective, required context, allowed files, forbidden files, expected output, verification, and stop conditions.
-3. State whether execution is real-subagent, sequential-role, or handoff-session.
-4. Verify fallback says no real delegation occurred when subagent tools are unavailable.
-5. Verify final evidence distinguishes result, verified, and accepted.
-
-## Evidence Requirements
-
-Every forward-test record should include:
-
-```text
-Forward-test level:
-Scenario:
-Changed behavior:
-Commands or inspection:
-Result evidence:
-Verification evidence:
-Accepted by:
-Residual risk:
-Next action:
-```
-
-Use `accepted by: policy` only when the applicable policy is named. Use `accepted by: fresh-session` only when a separate agent/session actually ran the path.
-
-Use `assets/templates/acceptance-execution-packet.md` when a fresh-session or owner-approved project write needs an explicit execution boundary before acceptance can be claimed.
-
-## Acceptance Rules
-
-- Structural smoke can make a slice `verified` for file/routing coverage.
-- Fixture forward test can make a workflow `verified` for the tested scenario.
-- Fresh-session forward test can support `accepted` when the fresh agent completes the intended path with only the documented GSE inputs.
-- If only structural smoke ran, record the remaining need for fixture or fresh-session testing as residual risk.
-- If a host tool is unavailable, the fallback path can be verified, but the unavailable tool capability is not verified.
-
-## Failure Handling
-
-If a forward test fails:
-
-1. Record the exact missing context, broken route, command failure, or ambiguity.
-2. Fix the smallest reusable artifact: script, template, reference, router, or gate.
-3. Re-run the same scenario.
-4. Add a learning entry only when the failure is reusable beyond the current slice.
-
-## Integration Points
-
-- `references/evidence-taxonomy.md` decides result, verified, and accepted status.
-- `references/benchmark-audit.md` decides when a GSE change needs forward-test coverage.
-- `references/quality-gates.md` applies forward-test requirements before completion.
-- `scripts/audit-project.mjs` verifies bootstrap scaffold generation and rerun safety in temporary project directories.
-- `scripts/audit-fixtures.mjs` provides a lightweight fixture audit for project-profile discovery and host-adapter/drift scenarios.
-- `.gse/evidence/YYYY-MM-DD.md` records scenario, commands, results, residual risk, and next action.
+# Forward Test Protocol
+
+Use this when changing GSE itself, changing reusable project scaffolds, or changing workflow rules that future agents must follow.
+
+Forward testing asks: can a future agent, fresh session, or fixture project use this change without relying on the author's memory?
+
+## Test Levels
+
+| Level | Meaning | Evidence gate | Use when |
+|---|---|---|---|
+| Structural smoke | Files, routing, audit criteria, and key text exist | verified for structure | Small reference/template/script changes |
+| Fixture forward test | A temp project or example repo uses the GSE path end to end | verified for workflow behavior | Bootstrap/profile/templates/adapters change |
+| Fresh-session forward test | A separate agent/session follows GSE with minimal context | accepted candidate | Non-trivial skill behavior, routing, multi-agent, release, recovery, or public-facing workflow changes |
+
+Do not call structural smoke a true forward-test acceptance. It proves the artifact is wired; it does not prove future-agent usability.
+
+## When Required
+
+Forward testing is required for:
+
+- New or changed scripts under `scripts/` that future projects will run.
+- Project scaffold changes under `scripts/init-project.mjs` or `assets/templates/` that affect downstream projects.
+- Router, quality gate, evidence, role, ownership, host adapter, release, recovery, or packaging rules.
+- Any change that claims a GSE capability is accepted rather than merely present or structurally verified.
+
+Forward testing is optional for:
+
+- Narrow wording edits that do not change behavior.
+- Evidence log updates.
+- Internal goal-map/current-slice status updates.
+- Small typo fixes in already tested references.
+
+Forward testing is unnecessary for:
+
+- Purely transient notes.
+- Local-only command output not used as reusable workflow evidence.
+- Work explicitly marked as draft or design judgment.
+
+## Core Scenarios
+
+Pick the smallest scenario that covers the changed behavior.
+
+### Fresh Project Bootstrap
+
+Use when bootstrap, templates, project profile, quality gates, or scaffold layout changes.
+
+Smoke:
+
+1. Create a temp project directory.
+2. Run `node <gse>/scripts/init-project.mjs --target <temp> --mode lite|standard|enterprise` as appropriate.
+3. Verify expected `.gse/` files exist.
+4. Verify rerun safety without `--force` when relevant.
+5. Record generated-file and cleanup policy.
+
+### Existing Repo Adoption
+
+Use when project-profile, discovery, dirty-worktree, tool adapters, or quality gates change.
+
+Smoke:
+
+1. Use a fixture or temp repo with representative files such as `package.json`, `AGENTS.md`, CI config, browser config, and `.env.example`.
+2. Run discovery or manual project-profile steps.
+3. Verify tool statuses stay `documented`, `verified`, `unknown`, or `unavailable` without inventing support.
+4. Verify dirty or pre-existing files are not overwritten.
+
+### Host Adapter Usage
+
+Use when `.codex/`, `.claude/`, `.agents/`, Hermes/AION-style runtime, WorkBuddy, MCP, hook, skill, or plugin adapter rules change.
+
+Smoke:
+
+1. Create or inspect a host adapter note using `assets/templates/host-adapter.md`.
+2. Confirm it points back to `.gse/` as source of truth.
+3. Mark host-specific capabilities with tool status evidence.
+4. Confirm no unsupported subagent, MCP, hook, or browser capability is claimed as verified.
+
+### Subagent Or Role Fallback
+
+Use when agent roles, dispatch packets, ownership, review, or multi-agent rules change.
+
+Smoke:
+
+1. Fill `assets/templates/dispatch-packet.md` for one locator, builder, reviewer, QA, or docs role.
+2. Include role, objective, required context, allowed files, forbidden files, expected output, verification, and stop conditions.
+3. State whether execution is real-subagent, sequential-role, or handoff-session.
+4. Verify fallback says no real delegation occurred when subagent tools are unavailable.
+5. Verify final evidence distinguishes result, verified, and accepted.
+
+## Evidence Requirements
+
+Every forward-test record should include:
+
+```text
+Forward-test level:
+Scenario:
+Changed behavior:
+Commands or inspection:
+Result evidence:
+Verification evidence:
+Accepted by:
+Residual risk:
+Next action:
+```
+
+Use `accepted by: policy` only when the applicable policy is named. Use `accepted by: fresh-session` only when a separate agent/session actually ran the path.
+
+Use `assets/templates/acceptance-execution-packet.md` when a fresh-session or owner-approved project write needs an explicit execution boundary before acceptance can be claimed.
+
+## Acceptance Rules
+
+- Structural smoke can make a slice `verified` for file/routing coverage.
+- Fixture forward test can make a workflow `verified` for the tested scenario.
+- Fresh-session forward test can support `accepted` when the fresh agent completes the intended path with only the documented GSE inputs.
+- If only structural smoke ran, record the remaining need for fixture or fresh-session testing as residual risk.
+- If a host tool is unavailable, the fallback path can be verified, but the unavailable tool capability is not verified.
+
+## Failure Handling
+
+If a forward test fails:
+
+1. Record the exact missing context, broken route, command failure, or ambiguity.
+2. Fix the smallest reusable artifact: script, template, reference, router, or gate.
+3. Re-run the same scenario.
+4. Add a learning entry only when the failure is reusable beyond the current slice.
+
+## Integration Points
+
+- `references/evidence-taxonomy.md` decides result, verified, and accepted status.
+- `references/benchmark-audit.md` decides when a GSE change needs forward-test coverage.
+- `references/quality-gates.md` applies forward-test requirements before completion.
+- `scripts/audit-project.mjs` verifies bootstrap scaffold generation and rerun safety in temporary project directories.
+- `scripts/audit-fixtures.mjs` provides a lightweight fixture audit for project-profile discovery and host-adapter/drift scenarios.
+- `.gse/evidence/YYYY-MM-DD.md` records scenario, commands, results, residual risk, and next action.

package/references/goal-map.md

@@ -1,36 +1,36 @@
-# Goal Map
-
-Goal maps keep long-running agent work from drifting.
-
-## Minimal Goal Node
-
-```yaml
-id: short-id
-title: Human-readable goal
-outcome: User or business outcome
-status: planned | in_progress | verified | accepted | blocked
-priority: P0 | P1 | P2 | P3
-dependencies: []
-acceptance: []
-evidence: []
-risks: []
-next_slice: Short next action
-last_updated: YYYY-MM-DD
-```
-
-## Update Rules
-
-- Keep the goal map short enough to guide the next session.
-- Put long logs under `.gse/evidence/` or project-specific evidence logs.
-- Update status only when evidence supports the change.
-- Show the next three slices for large projects.
-
-## Drift Checks
-
-Run a goal-map review when:
-
-- The same topic repeats without progress.
-- A module is marked done but lacks evidence.
-- The project has many commits but no visible product progress.
-- Agent sessions keep rediscovering the same context.
-
+# Goal Map
+
+Goal maps keep long-running agent work from drifting.
+
+## Minimal Goal Node
+
+```yaml
+id: short-id
+title: Human-readable goal
+outcome: User or business outcome
+status: planned | in_progress | verified | accepted | blocked
+priority: P0 | P1 | P2 | P3
+dependencies: []
+acceptance: []
+evidence: []
+risks: []
+next_slice: Short next action
+last_updated: YYYY-MM-DD
+```
+
+## Update Rules
+
+- Keep the goal map short enough to guide the next session.
+- Put long logs under `.gse/evidence/` or project-specific evidence logs.
+- Update status only when evidence supports the change.
+- Show the next three slices for large projects.
+
+## Drift Checks
+
+Run a goal-map review when:
+
+- The same topic repeats without progress.
+- A module is marked done but lacks evidence.
+- The project has many commits but no visible product progress.
+- Agent sessions keep rediscovering the same context.
+

package/references/host-adapters.md

@@ -1,119 +1,147 @@
-# Host Adapters
-
-Use this when a project needs GSE to work across Codex, Claude Code, Hermes/AION-style runtimes, WorkBuddy, Copilot-style agents, Gemini-style agents, or another agent host. Use `references/compatibility.md` to check host support status and adoption evidence before making capability claims.
-
+# Host Adapters
+
+Use this when a project needs GSE to work across Codex, Claude Code, Hermes/AION-style runtimes, WorkBuddy, Copilot-style agents, Gemini-style agents, or another agent host. Use `references/compatibility.md` to check host support status and adoption evidence before making capability claims.
+
 ## Core Rule
 
 `.gse/` is the portable source of truth. Host-specific folders are adapters.
 
 Adapters may expose commands, hooks, skills, MCP servers, indexes, or local UI metadata for one host, but they must point back to `.gse/` for project policy, goals, evidence, quality gates, and learning rules.
 
-## Adapter Decision
-
-Create or update a host adapter only when at least one condition is true:
-
-- The host has a real folder, command, hook, skill, MCP, index, or plugin mechanism.
-- The project already has host-specific rules that future agents need to find.
-- A host-specific capability needs a short pointer to `.gse/` to avoid duplicate policy.
-- A migration is needed from an existing `.claude/`, `.codex/`, `.agents/`, or runtime-specific workflow into `.gse/`.
-
-Do not create host folders just for decoration. If the host capability is unknown, document it as `unknown` in `.gse/project-profile.md` or `.gse/tooling.md`.
-
-## Supported Host Shapes
-
-| Host shape | Common adapter location | Adapter should contain | Must not contain |
-|---|---|---|---|
-| Codex-style | `.codex/`, Codex skills, MCP config | Pointer to `.gse/`, skill routing notes, MCP/index notes when verified | Full duplicate goal map or stale project rules |
-| Claude Code-style | `.claude/commands/`, `.claude/agents/`, `.claude/hooks/` | Command/agent/hook entrypoints that read `.gse/` first | Independent process constitution that conflicts with `.gse/` |
-| Hermes/AION-style runtime | runtime skills, worker adapters, memory/tool substrate docs | Runtime bridge notes and internal capability mapping | User-facing product identity or runtime leakage |
-| WorkBuddy/other IDE agents | local docs, plugin settings, task templates | How that host finds `.gse/` and which tools are verified | Claims that unsupported subagent or tool APIs exist |
-| Copilot/Gemini-style assistants | repository instructions, workspace docs | Short instruction to use `.gse/project-profile.md` and relevant gates | Host-specific long workflow copies |
-
-## Adapter Contents
-
-Use `assets/templates/host-adapter.md` for each adapter note.
-
-For command adapters, use:
-
-```text
-node <gse-skill>/scripts/generate-command-adapter.mjs --target <project-root> --host claude|codex|hermes|workbuddy|copilot|gemini|generic|all
-```
-
-This creates the smallest host command pointer available for the selected host. Generated files must still point back to `.gse/`.
-
-Generated command adapter locations:
-
-| Host | Generated path | Native slash-command claim |
-|---|---|---|
-| Claude Code-style | `.claude/commands/gse.md` | yes, file-shape only; runtime proof still needs a host invocation record |
-| Codex-style | `.codex/gse-command.md` | no |
-| Hermes/AION-style runtime | `.gse/host-adapters/hermes-runtime.md` | no |
-| WorkBuddy-style IDE agent | `.gse/host-adapters/workbuddy.md` | no |
-| GitHub Copilot-style assistant | `.github/copilot-instructions.md` | no |
-| Gemini-style assistant | `GEMINI.md` | no |
-| Generic or unknown agent host | `.gse/host-adapters/generic-agent.md` | no |
-
-The Hermes, WorkBuddy, Copilot, Gemini, and generic adapters are portable pointers. They exist to prevent host workflow drift, not to prove runtime support.
-
-For real host execution evidence, use:
-
-```text
-node <gse-skill>/scripts/record-host-invocation.mjs --root <skill-or-project> --host <host> --invocation-method <method> --evidence-owner <owner> --evidence <thread-or-log> --portable-text-command true --native-slash-command false
-```
-
-Then run:
-
-```text
-node <gse-skill>/scripts/audit-host-runtime-invocations.mjs --root <skill-or-project>
-```
-
-Before release handoff or cross-host claims, run the fixture drill:
-
-```text
-node <gse-skill>/scripts/audit-host-runtime-invocation-drill.mjs --root <skill-or-project>
-```
-
-The drill writes temporary records for Claude, Codex, Hermes/AION-style, WorkBuddy, and generic hosts, then audits native versus portable evidence counts. It proves the record/audit mechanics only; it does not prove real host runtime support.
-
+Process skills such as OpenSpec, Superpowers, Comet, and GSE can define workflow discipline, specs, roles, evidence, and quality gates. They do not create host-native slash commands, real subagent dispatch, browser automation, MCP servers, LSP indexes, CI runners, or host UI integration. Treat those as host capabilities and verify them through records before claiming support.
+
+## Adapter Decision
+
+Create or update a host adapter only when at least one condition is true:
+
+- The host has a real folder, command, hook, skill, MCP, index, or plugin mechanism.
+- The project already has host-specific rules that future agents need to find.
+- A host-specific capability needs a short pointer to `.gse/` to avoid duplicate policy.
+- A migration is needed from an existing `.claude/`, `.codex/`, `.agents/`, or runtime-specific workflow into `.gse/`.
+
+Do not create host folders just for decoration. If the host capability is unknown, document it as `unknown` in `.gse/project-profile.md`, `.gse/tooling.md`, or `.gse/host-capabilities.md`.
+
+## Supported Host Shapes
+
+| Host shape | Common adapter location | Adapter should contain | Must not contain |
+|---|---|---|---|
+| Codex-style | `.codex/`, Codex skills, MCP config | Pointer to `.gse/`, skill routing notes, MCP/index notes when verified | Full duplicate goal map or stale project rules |
+| Claude Code-style | `.claude/commands/`, `.claude/agents/`, `.claude/hooks/` | Command/agent/hook entrypoints that read `.gse/` first | Independent process constitution that conflicts with `.gse/` |
+| Hermes/AION-style runtime | runtime skills, worker adapters, memory/tool substrate docs | Runtime bridge notes and internal capability mapping | User-facing product identity or runtime leakage |
+| WorkBuddy/other IDE agents | local docs, plugin settings, task templates | How that host finds `.gse/` and which tools are verified | Claims that unsupported subagent or tool APIs exist |
+| Copilot/Gemini-style assistants | repository instructions, workspace docs | Short instruction to use `.gse/project-profile.md` and relevant gates | Host-specific long workflow copies |
+
+## Adapter Contents
+
+Use `assets/templates/host-adapter.md` for each adapter note.
+
+For command adapters, use:
+
+```text
+node <gse-skill>/scripts/generate-command-adapter.mjs --target <project-root> --host claude|codex|hermes|workbuddy|copilot|gemini|generic|all
+```
+
+This creates the smallest host command pointer available for the selected host. Generated files must still point back to `.gse/`.
+
+Generated command adapter locations:
+
+| Host | Generated path | Native slash-command claim |
+|---|---|---|
+| Claude Code-style | `.claude/commands/gse.md` | yes, file-shape only; runtime proof still needs a host invocation record |
+| Codex-style | `.codex/gse-command.md` | no |
+| Hermes/AION-style runtime | `.gse/host-adapters/hermes-runtime.md` | no |
+| WorkBuddy-style IDE agent | `.gse/host-adapters/workbuddy.md` | no |
+| GitHub Copilot-style assistant | `.github/copilot-instructions.md` | no |
+| Gemini-style assistant | `GEMINI.md` | no |
+| Generic or unknown agent host | `.gse/host-adapters/generic-agent.md` | no |
+
+The Hermes, WorkBuddy, Copilot, Gemini, and generic adapters are portable pointers. They exist to prevent host workflow drift, not to prove runtime support.
+
+For real host execution evidence, use:
+
+```text
+node <gse-skill>/scripts/record-host-invocation.mjs --root <skill-or-project> --host <host> --invocation-method <method> --evidence-owner <owner> --evidence <thread-or-log> --portable-text-command true --native-slash-command false
+```
+
+Then run:
+
+```text
+node <gse-skill>/scripts/audit-host-runtime-invocations.mjs --root <skill-or-project>
+```
+
+Before release handoff or cross-host claims, run the fixture drill:
+
+```text
+node <gse-skill>/scripts/audit-host-runtime-invocation-drill.mjs --root <skill-or-project>
+```
+
+The drill writes temporary records for Claude, Codex, Hermes/AION-style, WorkBuddy, and generic hosts, then audits native versus portable evidence counts. It proves the record/audit mechanics only; it does not prove real host runtime support.
+
 Generated adapters are not runtime proof. A host capability becomes verified only when a persistent host invocation record exists and the audit can parse it.
 
 Minimum fields:
-
-- Host name and adapter path.
-- Source of truth: always `.gse/` unless the project explicitly says otherwise.
-- Verified capabilities: commands, hooks, MCP, LSP/index, subagents, browser, CI.
-- Unverified or unavailable capabilities.
-- How to start meaningful work in this host.
-- Safety and permissions.
+
+- Host name and adapter path.
+- Source of truth: always `.gse/` unless the project explicitly says otherwise.
+- Verified capabilities: commands, hooks, MCP, LSP/index, subagents, browser, CI.
+- Unverified or unavailable capabilities.
+- How to start meaningful work in this host.
+- Safety and permissions.
 - Drift check owner or cadence.
 
-## Tool Status Rules
+## Host Capability Records
 
-Use the same vocabulary as `references/tool-adapters.md`:
+Use `.gse/host-capabilities.md` to keep a compact, auditable status table for host-native and tool capabilities:
 
-- `verified`: checked in this project or trusted local docs.
-- `documented`: present in docs or config, not tested in this session.
-- `unknown`: not confirmed.
-- `unavailable`: expected but missing or failing.
+- `native-slash-command`
+- `browser`
+- `mcp`
+- `lsp`
+- `subagent`
+- `ci`
 
-Never mark a host capability as `verified` because another host has it. Subagents, hooks, MCP, and browser tools are host-specific.
+Status vocabulary: `verified`, `documented`, `unknown`, `unavailable`, `external-required`.
 
-## Drift Prevention
+Rules:
 
-Use `references/drift-audit.md` when host-specific folders, hooks, skills, MCP, subagents, runtime adapters, or capability claims may have drifted from `.gse/`.
+- `verified` needs concrete project or host evidence.
+- Native slash-command support cannot be verified from portable `run-gse-command.mjs` output.
+- `documented` and `external-required` rows must include a claim boundary.
+- Missing records are a continuation warning for new projects; invalid or overclaimed records fail the host capability audit.
 
-When adding a host adapter:
+Audit command:
 
-1. Keep policy in `.gse/` and link back from the host folder.
-2. Copy only the shortest host-specific command or pointer needed.
-3. Add the adapter to `.gse/project-profile.md` under `Agent Host Adapters`.
-4. Add any verified commands to `.gse/tooling.md`.
-5. If the adapter changes task routing, update `.gse/goal-map.md` or `.gse/quality-gates.md` only once in the portable layer.
-
-## Review Checklist
-
-- Does the adapter point to `.gse/` before host-specific instructions?
-- Are verified and unverified capabilities separated?
-- Are secrets and write-capable tools documented without exposing credentials?
-- Is there only one authoritative goal map and evidence location?
-- Can a future agent using a different host still follow the project workflow?
+```text
+node <gse-skill>/scripts/audit-host-capabilities.mjs --target <project-root> --json
+```
+
+## Tool Status Rules
+
+Use the same vocabulary as `references/tool-adapters.md`:
+
+- `verified`: checked in this project or trusted local docs.
+- `documented`: present in docs or config, not tested in this session.
+- `unknown`: not confirmed.
+- `unavailable`: expected but missing or failing.
+
+Never mark a host capability as `verified` because another host has it. Subagents, hooks, MCP, and browser tools are host-specific.
+
+## Drift Prevention
+
+Use `references/drift-audit.md` when host-specific folders, hooks, skills, MCP, subagents, runtime adapters, or capability claims may have drifted from `.gse/`.
+
+When adding a host adapter:
+
+1. Keep policy in `.gse/` and link back from the host folder.
+2. Copy only the shortest host-specific command or pointer needed.
+3. Add the adapter to `.gse/project-profile.md` under `Agent Host Adapters`.
+4. Add any verified commands to `.gse/tooling.md`.
+5. If the adapter changes task routing, update `.gse/goal-map.md` or `.gse/quality-gates.md` only once in the portable layer.
+
+## Review Checklist
+
+- Does the adapter point to `.gse/` before host-specific instructions?
+- Are verified and unverified capabilities separated?
+- Are secrets and write-capable tools documented without exposing credentials?
+- Is there only one authoritative goal map and evidence location?
+- Can a future agent using a different host still follow the project workflow?