@t275005746/gse 0.1.0 → 0.1.1

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,119 @@
-# 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.
-
-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.
-- Drift check owner or cadence.
-
-## 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?
+# 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.
+
+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.
+- Drift check owner or cadence.
+
+## 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?

package/references/learning-system.md

@@ -1,35 +1,35 @@
-# Learning System
-
-Learnings keep long projects from repeating mistakes.
-
-## Capture When
-
-- User corrects an assumption.
-- A command, tool, API, or integration fails unexpectedly.
-- A bug root cause was non-obvious.
-- A recurring workflow can be shortened or hardened.
-- A missing quality gate allowed a defect through.
-
-## Do Not Capture
-
-- Raw chain of thought.
-- Temporary attempts.
-- Long command output.
-- One-off details unlikely to help future work.
-
-## Upgrade Rule
-
-Use `references/drift-audit.md` when a repeated lesson suggests stale docs, stale project-profile facts, stale host adapters, stale tool assumptions, or stale evidence state.
-
-- First occurrence: learning note.
-- Second occurrence: checklist or template update.
-- Third occurrence: project rule or quality gate.
-- Fifth occurrence: script, test, or dedicated skill.
-
-## Suggested Stores
-
-- `.gse/learnings.md` for portable project lessons.
-- `.learnings/` when the project already uses that convention.
-- `AGENTS.md` for durable project rules.
-- ADRs for architectural decisions.
-
+# Learning System
+
+Learnings keep long projects from repeating mistakes.
+
+## Capture When
+
+- User corrects an assumption.
+- A command, tool, API, or integration fails unexpectedly.
+- A bug root cause was non-obvious.
+- A recurring workflow can be shortened or hardened.
+- A missing quality gate allowed a defect through.
+
+## Do Not Capture
+
+- Raw chain of thought.
+- Temporary attempts.
+- Long command output.
+- One-off details unlikely to help future work.
+
+## Upgrade Rule
+
+Use `references/drift-audit.md` when a repeated lesson suggests stale docs, stale project-profile facts, stale host adapters, stale tool assumptions, or stale evidence state.
+
+- First occurrence: learning note.
+- Second occurrence: checklist or template update.
+- Third occurrence: project rule or quality gate.
+- Fifth occurrence: script, test, or dedicated skill.
+
+## Suggested Stores
+
+- `.gse/learnings.md` for portable project lessons.
+- `.learnings/` when the project already uses that convention.
+- `AGENTS.md` for durable project rules.
+- ADRs for architectural decisions.
+