@t275005746/gse 0.1.0 → 0.1.1

package/references/router.md

@@ -1,90 +1,90 @@
-# Router
-
-Use this to choose the GSE path before loading detailed references. The router selects; it does not replace the selected reference files.
-
-## Inputs
-
-Classify the request with these inputs:
-
-- Work target: GSE skill itself, a project adopting GSE, or ordinary project work inside a GSE project.
-- Task level: Lite, Standard, or Enterprise from `task-levels.md`.
-- Change type: setup, feature, bug, refactor, research, UI, release, incident, skill improvement, or tool adapter.
-- Tool availability: verified, documented, unknown, or unavailable from `tool-adapters.md`.
-- Project constraints: `.gse/project-profile.md`, AGENTS/CLAUDE/GEMINI rules, CI, MCP, LSP, browser, release, and security boundaries.
-- Command-style usage: `/gse ...`, `gse: ...`, or equivalent natural-language command from `commands.md`.
-
-## Universal Start
-
-For meaningful work:
-
-1. Read project or skill rules first.
-2. Read `.gse/project-profile.md` when working inside a project.
-3. Read `.gse/gse-design-master-plan.md`, `.gse/goal-map.md`, and `.gse/current-slice.md` when improving GSE itself.
-4. If the request starts with `/gse` or `gse:`, load `references/commands.md` and map the command before selecting the route.
-5. Select one route below.
-6. Load only the reference files required by that route.
-
-## Route Map
-
-| Situation | Route | Required References | Optional Adapters |
-|---|---|---|---|
-| User asks `/gse ...` or `gse: ...` | Command routing | `commands.md`, then the mapped route reference | host-specific slash command adapters |
-| Improve GSE skill itself | GSE self-development | `.gse/gse-development-protocol.md`, `.gse/gse-design-master-plan.md`, `benchmark-audit.md` | `audit-gse.mjs`, `skill-creator`, benchmark repos |
-| Initialize GSE in a project | Project bootstrap | `project-bootstrap.md`, `project-profile.md`, `project-agent-workspace.md` | `init-project.mjs` |
-| Discover project rules/tools | Project profile | `project-profile.md`, `tool-adapters.md` | future `discover-project-profile.mjs`, LSP, MCP, CI |
-| Plan feature or product slice | Spec workflow | `task-levels.md`, `goal-map.md`, `spec-workflow.md`, `quality-gates.md` | OpenSpec, Comet, subagents |
-| Implement bounded slice | Execute workflow | `operating-model.md`, `quality-gates.md`, `tool-adapters.md` | TDD, LSP, browser QA, CI |
-| Debug bug or incident | Recovery workflow | `quality-gates.md`, `learning-system.md`; add recovery reference when available | browser/API smoke, logs, incident review |
-| UI or browser-visible change | UI verification | `quality-gates.md`, `tool-adapters.md`, project profile | Browser, Playwright, screenshots |
-| Multi-agent execution | Role workflow | `agent-roles.md`, `quality-gates.md` | subagent tools, worktrees, file ownership reference when available |
-| Release or migration | Release workflow | `quality-gates.md`; add release reference when available | CI, deployment, smoke, rollback |
-| Add or evaluate tool adapter | Adapter workflow | `tool-adapters.md`, `project-profile.md`, `benchmark-audit.md` for GSE changes | MCP, LSP, browser, model routing |
-| Record reusable lesson | Learning workflow | `learning-system.md` | self-improvement |
-
-## Level Rules
-
-Lite:
-
-- Use when the task is small, local, low-risk, and independently verifiable.
-- Keep artifacts minimal: outcome, scope, acceptance, evidence, next action.
-- Do not create a change folder unless it prevents confusion.
-
-Standard:
-
-- Use for user-visible behavior, API/state changes, multi-file edits, project setup, or GSE reference/script changes.
-- Bind to goal map or current slice.
-- Record evidence in `.gse/evidence/` or the project evidence log.
-
-Enterprise:
-
-- Use for cross-module architecture, release, migration, security, multi-agent execution, compliance, or long-running productization.
-- Require explicit gates for risk, rollback, ownership, verification, and learning.
-
-## Tool Routing Rules
-
-- Use `rg`/`rg --files` first for code and file discovery.
-- Use LSP/index when verified or documented for the project.
-- Use browser/Playwright for user-visible UI behavior.
-- Use API smoke or focused tests for API/state behavior.
-- Use OpenSpec or Comet when the project has them and the change benefits from formal lifecycle artifacts.
-- Use subagents only when real dispatch tools exist; otherwise execute roles sequentially and say so.
-- Use markdown fallback when optional tools are unavailable.
-
-## GSE Self-Development Route
-
-When changing GSE itself:
-
-1. Read `.gse/gse-design-master-plan.md`, `.gse/goal-map.md`, and `.gse/current-slice.md`.
-2. Run or consult `scripts/audit-gse.mjs` to see current structural gaps.
-3. If the change is non-trivial, update or create a benchmark audit.
-4. Prefer scripts/templates/gates for repeatable behavior.
-5. Validate with focused smoke.
-6. Update `.gse/evidence/YYYY-MM-DD.md`, goal map, and current slice.
-
-## Anti-Routes
-
-- Do not use GSE as a reason to ignore project rules.
-- Do not load every reference file by default.
-- Do not treat optional tools as hard prerequisites.
-- Do not claim a route succeeded without evidence.
-- Do not keep adding prose when a script or template would make the behavior repeatable.
+# Router
+
+Use this to choose the GSE path before loading detailed references. The router selects; it does not replace the selected reference files.
+
+## Inputs
+
+Classify the request with these inputs:
+
+- Work target: GSE skill itself, a project adopting GSE, or ordinary project work inside a GSE project.
+- Task level: Lite, Standard, or Enterprise from `task-levels.md`.
+- Change type: setup, feature, bug, refactor, research, UI, release, incident, skill improvement, or tool adapter.
+- Tool availability: verified, documented, unknown, or unavailable from `tool-adapters.md`.
+- Project constraints: `.gse/project-profile.md`, AGENTS/CLAUDE/GEMINI rules, CI, MCP, LSP, browser, release, and security boundaries.
+- Command-style usage: `/gse ...`, `gse: ...`, or equivalent natural-language command from `commands.md`.
+
+## Universal Start
+
+For meaningful work:
+
+1. Read project or skill rules first.
+2. Read `.gse/project-profile.md` when working inside a project.
+3. Read `.gse/gse-design-master-plan.md`, `.gse/goal-map.md`, and `.gse/current-slice.md` when improving GSE itself.
+4. If the request starts with `/gse` or `gse:`, load `references/commands.md` and map the command before selecting the route.
+5. Select one route below.
+6. Load only the reference files required by that route.
+
+## Route Map
+
+| Situation | Route | Required References | Optional Adapters |
+|---|---|---|---|
+| User asks `/gse ...` or `gse: ...` | Command routing | `commands.md`, then the mapped route reference | host-specific slash command adapters |
+| Improve GSE skill itself | GSE self-development | `.gse/gse-development-protocol.md`, `.gse/gse-design-master-plan.md`, `benchmark-audit.md` | `audit-gse.mjs`, `skill-creator`, benchmark repos |
+| Initialize GSE in a project | Project bootstrap | `project-bootstrap.md`, `project-profile.md`, `project-agent-workspace.md` | `init-project.mjs` |
+| Discover project rules/tools | Project profile | `project-profile.md`, `tool-adapters.md` | future `discover-project-profile.mjs`, LSP, MCP, CI |
+| Plan feature or product slice | Spec workflow | `task-levels.md`, `goal-map.md`, `spec-workflow.md`, `quality-gates.md` | OpenSpec, Comet, subagents |
+| Implement bounded slice | Execute workflow | `operating-model.md`, `quality-gates.md`, `tool-adapters.md` | TDD, LSP, browser QA, CI |
+| Debug bug or incident | Recovery workflow | `quality-gates.md`, `learning-system.md`; add recovery reference when available | browser/API smoke, logs, incident review |
+| UI or browser-visible change | UI verification | `quality-gates.md`, `tool-adapters.md`, project profile | Browser, Playwright, screenshots |
+| Multi-agent execution | Role workflow | `agent-roles.md`, `quality-gates.md` | subagent tools, worktrees, file ownership reference when available |
+| Release or migration | Release workflow | `quality-gates.md`; add release reference when available | CI, deployment, smoke, rollback |
+| Add or evaluate tool adapter | Adapter workflow | `tool-adapters.md`, `project-profile.md`, `benchmark-audit.md` for GSE changes | MCP, LSP, browser, model routing |
+| Record reusable lesson | Learning workflow | `learning-system.md` | self-improvement |
+
+## Level Rules
+
+Lite:
+
+- Use when the task is small, local, low-risk, and independently verifiable.
+- Keep artifacts minimal: outcome, scope, acceptance, evidence, next action.
+- Do not create a change folder unless it prevents confusion.
+
+Standard:
+
+- Use for user-visible behavior, API/state changes, multi-file edits, project setup, or GSE reference/script changes.
+- Bind to goal map or current slice.
+- Record evidence in `.gse/evidence/` or the project evidence log.
+
+Enterprise:
+
+- Use for cross-module architecture, release, migration, security, multi-agent execution, compliance, or long-running productization.
+- Require explicit gates for risk, rollback, ownership, verification, and learning.
+
+## Tool Routing Rules
+
+- Use `rg`/`rg --files` first for code and file discovery.
+- Use LSP/index when verified or documented for the project.
+- Use browser/Playwright for user-visible UI behavior.
+- Use API smoke or focused tests for API/state behavior.
+- Use OpenSpec or Comet when the project has them and the change benefits from formal lifecycle artifacts.
+- Use subagents only when real dispatch tools exist; otherwise execute roles sequentially and say so.
+- Use markdown fallback when optional tools are unavailable.
+
+## GSE Self-Development Route
+
+When changing GSE itself:
+
+1. Read `.gse/gse-design-master-plan.md`, `.gse/goal-map.md`, and `.gse/current-slice.md`.
+2. Run or consult `scripts/audit-gse.mjs` to see current structural gaps.
+3. If the change is non-trivial, update or create a benchmark audit.
+4. Prefer scripts/templates/gates for repeatable behavior.
+5. Validate with focused smoke.
+6. Update `.gse/evidence/YYYY-MM-DD.md`, goal map, and current slice.
+
+## Anti-Routes
+
+- Do not use GSE as a reason to ignore project rules.
+- Do not load every reference file by default.
+- Do not treat optional tools as hard prerequisites.
+- Do not claim a route succeeded without evidence.
+- Do not keep adding prose when a script or template would make the behavior repeatable.

package/references/spec-workflow.md

@@ -1,66 +1,66 @@
-# Spec Workflow
-
-Use specs to prevent agents from implementing vague intent.
-
-## Markdown Fallback
-
-Create `.gse/changes/<change-id>/` with:
-
-```text
-brief.md       # why and user outcome
-spec.md        # behavior and acceptance
-design.md      # approach, state, risk, privacy
-tasks.md       # verifiable slices
-evidence.md    # proof and verification
-review.md      # review findings and closure
-execution-quality-pack.md # skills, tool routing, quality gates, evidence, closure
-```
-
-Portable helper:
-
-```text
-node <gse-skill>/scripts/init-change.mjs --target <project-root> --change-id <change-id> --level lite|standard|enterprise
-```
-
-Close and archive helper:
-
-```text
-node <gse-skill>/scripts/close-change.mjs --target <project-root> --change-id <change-id> --status result|verified|accepted
-```
-
-Closing a change moves `.gse/changes/<change-id>/` to `.gse/archive/<date>-<change-id>/` and appends a `change-archive` record to `.gse/evidence/index.jsonl`.
-
-## Optional OpenSpec Adapter
-
-Use OpenSpec when the project has it and the task changes a capability, API, state machine, data model, or public contract.
-
-Expected OpenSpec artifacts:
-
-- proposal.md
-- design.md
-- tasks.md
-- delta specs
-
-## Optional Comet Adapter
-
-Use Comet when a full change lifecycle is useful and the skill/tools are installed.
-
-Comet is suitable for Level 2 and Level 3 work that benefits from open, design, build, verify, archive phases.
-
-## Optional Superpowers Adapter
-
-Use Superpowers when complex planning, staged execution, subagent orchestration, or multi-pass review is available and useful.
-
-GSE's native fallback is `execution-quality-pack.md` plus `references/quality-gates.md`, `references/domain-quality-gates.md`, `references/agent-roles.md`, and `references/review.md`.
-
-Do not require Superpowers for Lite tasks or when the current host does not expose the needed tools.
-
-## Spec Quality Checklist
-
-- User outcome is explicit.
-- Non-goals are explicit.
-- Acceptance is testable.
-- Error and recovery behavior is covered for risky paths.
-- Privacy and permission boundaries are stated when relevant.
-- Evidence type is known before implementation.
-- Execution skills, tool routing, selected quality gates, and review closure are explicit for Standard and Enterprise work.
+# Spec Workflow
+
+Use specs to prevent agents from implementing vague intent.
+
+## Markdown Fallback
+
+Create `.gse/changes/<change-id>/` with:
+
+```text
+brief.md       # why and user outcome
+spec.md        # behavior and acceptance
+design.md      # approach, state, risk, privacy
+tasks.md       # verifiable slices
+evidence.md    # proof and verification
+review.md      # review findings and closure
+execution-quality-pack.md # skills, tool routing, quality gates, evidence, closure
+```
+
+Portable helper:
+
+```text
+node <gse-skill>/scripts/init-change.mjs --target <project-root> --change-id <change-id> --level lite|standard|enterprise
+```
+
+Close and archive helper:
+
+```text
+node <gse-skill>/scripts/close-change.mjs --target <project-root> --change-id <change-id> --status result|verified|accepted
+```
+
+Closing a change moves `.gse/changes/<change-id>/` to `.gse/archive/<date>-<change-id>/` and appends a `change-archive` record to `.gse/evidence/index.jsonl`.
+
+## Optional OpenSpec Adapter
+
+Use OpenSpec when the project has it and the task changes a capability, API, state machine, data model, or public contract.
+
+Expected OpenSpec artifacts:
+
+- proposal.md
+- design.md
+- tasks.md
+- delta specs
+
+## Optional Comet Adapter
+
+Use Comet when a full change lifecycle is useful and the skill/tools are installed.
+
+Comet is suitable for Level 2 and Level 3 work that benefits from open, design, build, verify, archive phases.
+
+## Optional Superpowers Adapter
+
+Use Superpowers when complex planning, staged execution, subagent orchestration, or multi-pass review is available and useful.
+
+GSE's native fallback is `execution-quality-pack.md` plus `references/quality-gates.md`, `references/domain-quality-gates.md`, `references/agent-roles.md`, and `references/review.md`.
+
+Do not require Superpowers for Lite tasks or when the current host does not expose the needed tools.
+
+## Spec Quality Checklist
+
+- User outcome is explicit.
+- Non-goals are explicit.
+- Acceptance is testable.
+- Error and recovery behavior is covered for risky paths.
+- Privacy and permission boundaries are stated when relevant.
+- Evidence type is known before implementation.
+- Execution skills, tool routing, selected quality gates, and review closure are explicit for Standard and Enterprise work.

package/references/task-levels.md

@@ -1,81 +1,81 @@
-# Task Levels
-
-Classify before choosing process weight.
-
-## Level 1 - Lite
-
-Use for small bugs, small UI/copy changes, scripts, docs, and narrow refactors.
-
-Required artifacts:
-
-- Inline `Outcome / Scope / Acceptance / Evidence / Next action`
-- Focused verification command or manual evidence
-- Learning only when reusable
-
-No change folder required.
-
-Gate profile:
-
-- Run the narrowest focused test, smoke, structural check, or manual evidence that proves the changed behavior.
-- Do not run build/typecheck/browser/full close gates by default unless the changed file or failure mode specifically requires them.
-- Keep evidence inline or in the existing slice log; do not create long process artifacts for tiny state-only changes.
-
-## Level 2 - Standard
-
-Use for user-visible features, API changes, state-machine branches, cross-file behavior, or work expected to take more than one focused slice.
-
-Required artifacts:
-
-- Goal-map binding or project issue link
-- `.gse/changes/<change-id>/brief.md`
-- Acceptance and evidence log
-- Focused tests or smoke verification
-
-Use OpenSpec or Comet when available and suitable.
-
-Gate profile:
-
-- Run focused tests for changed behavior and one integration/API/UI smoke when the user-visible path needs it.
-- Run build/typecheck before commit when the slice touches shared TypeScript contracts, Next routing/build-time code, generated package shape, or release/install paths.
-- Prefer combining several tiny state-only changes into one user-visible product chain instead of committing each micro-state transition separately.
-
-## Level 3 - Enterprise
-
-Use for long-running product work, security, payments, data migrations, public contracts, release readiness, multi-agent coordination, or architecture changes.
-
-Required artifacts:
-
-- Goal-map node
-- Spec or RFC
-- Design notes, state machine, or risk matrix when relevant
-- Quality gates and rollback plan
-- Review and evidence
-- Learning review after completion
-
-Use OpenSpec, Comet, subagents, CI gates, browser automation, and ADRs when available.
-
-Gate profile:
-
-- Run focused verification plus the relevant hard gate for the risk: build, browser smoke, API smoke, install/distribution audit, security check, migration check, or close gate.
-- Use full validation only for release, public contract, scaffold/skill, install, cross-host, or high-blast-radius changes.
-- Keep evidence concise even when gates are heavy; link or summarize outputs instead of pasting logs.
-
-## Upgrade Triggers
-
-Upgrade one level when:
-
-- Scope touches 3+ modules.
-- A public API, data model, security boundary, or release process changes.
-- Failure would block users or corrupt data.
-- The same issue recurred.
-- The task needs multiple agents or multiple sessions.
-
-## Slice Sizing
-
-Prefer a slice that proves one user-visible chain or one production capability boundary.
-
-- Too small: only flips an internal status with no visible capability, no contract change, and no risk reduction.
-- Healthy: covers a coherent path such as `bundle ShotSpec -> shot acceptance -> QA seed`, with focused tests proving the path.
-- Too large: mixes unrelated product flows, broad refactors, and release/process changes that cannot be verified in one evidence pass.
-
-For long-running productization, merge adjacent tiny state-machine steps when they are only meaningful together, but keep the acceptance proof focused.
+# Task Levels
+
+Classify before choosing process weight.
+
+## Level 1 - Lite
+
+Use for small bugs, small UI/copy changes, scripts, docs, and narrow refactors.
+
+Required artifacts:
+
+- Inline `Outcome / Scope / Acceptance / Evidence / Next action`
+- Focused verification command or manual evidence
+- Learning only when reusable
+
+No change folder required.
+
+Gate profile:
+
+- Run the narrowest focused test, smoke, structural check, or manual evidence that proves the changed behavior.
+- Do not run build/typecheck/browser/full close gates by default unless the changed file or failure mode specifically requires them.
+- Keep evidence inline or in the existing slice log; do not create long process artifacts for tiny state-only changes.
+
+## Level 2 - Standard
+
+Use for user-visible features, API changes, state-machine branches, cross-file behavior, or work expected to take more than one focused slice.
+
+Required artifacts:
+
+- Goal-map binding or project issue link
+- `.gse/changes/<change-id>/brief.md`
+- Acceptance and evidence log
+- Focused tests or smoke verification
+
+Use OpenSpec or Comet when available and suitable.
+
+Gate profile:
+
+- Run focused tests for changed behavior and one integration/API/UI smoke when the user-visible path needs it.
+- Run build/typecheck before commit when the slice touches shared TypeScript contracts, Next routing/build-time code, generated package shape, or release/install paths.
+- Prefer combining several tiny state-only changes into one user-visible product chain instead of committing each micro-state transition separately.
+
+## Level 3 - Enterprise
+
+Use for long-running product work, security, payments, data migrations, public contracts, release readiness, multi-agent coordination, or architecture changes.
+
+Required artifacts:
+
+- Goal-map node
+- Spec or RFC
+- Design notes, state machine, or risk matrix when relevant
+- Quality gates and rollback plan
+- Review and evidence
+- Learning review after completion
+
+Use OpenSpec, Comet, subagents, CI gates, browser automation, and ADRs when available.
+
+Gate profile:
+
+- Run focused verification plus the relevant hard gate for the risk: build, browser smoke, API smoke, install/distribution audit, security check, migration check, or close gate.
+- Use full validation only for release, public contract, scaffold/skill, install, cross-host, or high-blast-radius changes.
+- Keep evidence concise even when gates are heavy; link or summarize outputs instead of pasting logs.
+
+## Upgrade Triggers
+
+Upgrade one level when:
+
+- Scope touches 3+ modules.
+- A public API, data model, security boundary, or release process changes.
+- Failure would block users or corrupt data.
+- The same issue recurred.
+- The task needs multiple agents or multiple sessions.
+
+## Slice Sizing
+
+Prefer a slice that proves one user-visible chain or one production capability boundary.
+
+- Too small: only flips an internal status with no visible capability, no contract change, and no risk reduction.
+- Healthy: covers a coherent path such as `bundle ShotSpec -> shot acceptance -> QA seed`, with focused tests proving the path.
+- Too large: mixes unrelated product flows, broad refactors, and release/process changes that cannot be verified in one evidence pass.
+
+For long-running productization, merge adjacent tiny state-machine steps when they are only meaningful together, but keep the acceptance proof focused.

package/references/tool-adapters.md

@@ -1,73 +1,73 @@
-# Tool Adapters
-
-GSE has few hard requirements. Tools enhance the workflow when available.
-
-## Minimum Tools
-
-- Git
-- A shell
-- Project build/test commands when present
-
-Recommended:
-
-- `rg` / `rg --files` for search
-- LSP for symbol navigation
-- Browser or Playwright for UI verification
-
-## Context and Code Location
-
-Use in order:
-
-1. Project rules: `AGENTS.md`, `CLAUDE.md`, README, or equivalent.
-2. `.gse/project-profile.md` for project-specific standards, commands, tools, and permissions.
-3. `.gse/README.md` and `goal-map.md` when present.
-4. `rg --files` and `rg` to find relevant code.
-5. LSP or code index when available.
-6. Existing tests and recent commits.
-
-Avoid broad reads of generated outputs, logs, lockfiles, or historical archives unless required.
-
-## Project-Specific Tools
-
-Use `references/drift-audit.md` when recorded tool status, command assumptions, MCP, LSP/index, browser, CI, package manager, or deployment facts may be stale.
-
-Use `project-profile.md` to record tool connections and status.
-
-Status vocabulary:
-
-- `verified`: command/config was tested or documented in a trusted project file.
-- `documented`: project docs mention it, but this session has not tested it.
-- `unknown`: not confirmed.
-- `unavailable`: expected but missing or failing.
-
-Project-specific commands and standards override generic recommendations. If the project says to use `pnpm`, `bun`, `make`, a custom smoke script, a specific LSP/index, or a private MCP server, follow that after verifying it is present or documenting its status.
-
-## Model Routing
-
-Use `references/model-routing.md` when choosing model, provider, hosted tool, worker, or role-specific agent capability. Record documented vs verified behavior separately.
-
-## Host Adapters
-
-Use `references/host-adapters.md` and `references/compatibility.md` when a project has `.codex/`, `.claude/`, `.agents/`, Hermes/AION-style runtime folders, WorkBuddy settings, MCP configs, hooks, local skills, or other host-specific workflow files.
-
-Host adapters are pointers and capability maps. They should not duplicate `.gse/goal-map.md`, `.gse/quality-gates.md`, or `.gse/evidence/`.
-
-## OpenSpec
-
-Use for capability specs and acceptance deltas. Fall back to `.gse/changes/` markdown when unavailable.
-
-## Comet
-
-Use for full change lifecycle when installed and suitable. Fall back to GSE change folders when unavailable.
-
-## Superpowers
-
-Use for complex plans, subagent-driven execution, and staged review. Do not force it on Level 1 work.
-
-## Self-Improvement
-
-Use when a user correction, repeated failure, tool gap, non-obvious root cause, or better recurring method is discovered.
-
-## Subagents
-
-Use when actual tools exist, such as `spawn_agent` / `wait_agent` or thread dispatch equivalents. Do not claim delegation when the tools are absent.
+# Tool Adapters
+
+GSE has few hard requirements. Tools enhance the workflow when available.
+
+## Minimum Tools
+
+- Git
+- A shell
+- Project build/test commands when present
+
+Recommended:
+
+- `rg` / `rg --files` for search
+- LSP for symbol navigation
+- Browser or Playwright for UI verification
+
+## Context and Code Location
+
+Use in order:
+
+1. Project rules: `AGENTS.md`, `CLAUDE.md`, README, or equivalent.
+2. `.gse/project-profile.md` for project-specific standards, commands, tools, and permissions.
+3. `.gse/README.md` and `goal-map.md` when present.
+4. `rg --files` and `rg` to find relevant code.
+5. LSP or code index when available.
+6. Existing tests and recent commits.
+
+Avoid broad reads of generated outputs, logs, lockfiles, or historical archives unless required.
+
+## Project-Specific Tools
+
+Use `references/drift-audit.md` when recorded tool status, command assumptions, MCP, LSP/index, browser, CI, package manager, or deployment facts may be stale.
+
+Use `project-profile.md` to record tool connections and status.
+
+Status vocabulary:
+
+- `verified`: command/config was tested or documented in a trusted project file.
+- `documented`: project docs mention it, but this session has not tested it.
+- `unknown`: not confirmed.
+- `unavailable`: expected but missing or failing.
+
+Project-specific commands and standards override generic recommendations. If the project says to use `pnpm`, `bun`, `make`, a custom smoke script, a specific LSP/index, or a private MCP server, follow that after verifying it is present or documenting its status.
+
+## Model Routing
+
+Use `references/model-routing.md` when choosing model, provider, hosted tool, worker, or role-specific agent capability. Record documented vs verified behavior separately.
+
+## Host Adapters
+
+Use `references/host-adapters.md` and `references/compatibility.md` when a project has `.codex/`, `.claude/`, `.agents/`, Hermes/AION-style runtime folders, WorkBuddy settings, MCP configs, hooks, local skills, or other host-specific workflow files.
+
+Host adapters are pointers and capability maps. They should not duplicate `.gse/goal-map.md`, `.gse/quality-gates.md`, or `.gse/evidence/`.
+
+## OpenSpec
+
+Use for capability specs and acceptance deltas. Fall back to `.gse/changes/` markdown when unavailable.
+
+## Comet
+
+Use for full change lifecycle when installed and suitable. Fall back to GSE change folders when unavailable.
+
+## Superpowers
+
+Use for complex plans, subagent-driven execution, and staged review. Do not force it on Level 1 work.
+
+## Self-Improvement
+
+Use when a user correction, repeated failure, tool gap, non-obvious root cause, or better recurring method is discovered.
+
+## Subagents
+
+Use when actual tools exist, such as `spawn_agent` / `wait_agent` or thread dispatch equivalents. Do not claim delegation when the tools are absent.