@t275005746/gse 0.1.0 → 0.1.1

package/references/benchmark-audit.md

@@ -1,73 +1,73 @@
-# Benchmark Audit
-
-Use this when improving GSE itself: changing the GSE skill, its scripts, templates, references, project scaffold, or development goals.
-
-## Purpose
-
-GSE development must proactively find workflow gaps. Do not wait for the user to discover missing requirements through manual testing.
-
-Run this audit against verified local skills, project files, tool help, official docs when available, and focused experiments. Label design judgments separately from verified facts.
-
-## Benchmark Sources
-
-Use the best available sources for the current host:
-
-- Local GSE files under `.gse/` or the skill folder.
-- Installed workflow skills: Comet, OpenSpec, Superpowers-style skills, agentic-engineering, subagent-driven-development, TDD, code review, self-improvement, QA, CI/CD.
-- Public or local skill repositories when explicitly referenced or already cloned, such as `mattpocock/skills`.
-- Project rules only when GSE is being tested inside a real project: `AGENTS.md`, `CLAUDE.md`, `CONTEXT.md`, ADRs, issue tracker docs, CI config, test scripts.
-- Official tool docs only when needed for a drift-prone claim.
-
-## GSE Development Audit Matrix
-
-Score each area as `missing`, `thin`, `usable`, or `strong`.
-
-| Area | Questions |
-|---|---|
-| Setup | Can a new agent install or initialize GSE without guessing? |
-| Router | Is there a clear map from user intent to GSE references, scripts, and modes? |
-| Goal Map | Are GSE's north star, current priority, risks, and next slice visible? |
-| Domain Model | Is shared language captured, challenged, and updated? |
-| Specs | Are GSE change outcome, scope, non-goals, contracts, and acceptance explicit? |
-| Task Slicing | Are tasks vertical, independently verifiable, and sized by risk? |
-| Tool Acceleration | Are search, LSP/index, browser, API, MCP, and CI tools recorded with fallbacks? |
-| Multi-Agent | Are roles, dispatch packets, file ownership, review gates, and no-fake-delegation rules clear? |
-| Implementation | Does GSE development preserve skill patterns and avoid unrelated expansion? |
-| Testing | Are focused tests, TDD, smoke, regression, and UI verification rules present? |
-| Review | Are spec compliance and code quality reviewed separately? |
-| Evidence | Is GSE change evidence recorded with commands and residual risk? |
-| Release | Are migration, rollout, rollback, smoke, and known-risk steps defined? |
-| Incident | Is there a path for failures, postmortems, and prevention gates? |
-| Learning | Are reusable lessons promoted into rules, gates, or templates? |
-| Context Hygiene | Are handoff, compaction, stale-context, and token-budget rules defined? |
-| Adapter Drift | Are host-specific GSE adapters prevented from diverging from the portable source of truth? |
-| Security | Are secrets, permissions, destructive tools, and external services bounded? |
-| Observability | Are traces, cost, retries, failures, and long-running state captured when relevant? |
-
-## Required Output
-
-```text
-Outcome:
-Benchmark sources:
-Strong areas:
-Gaps:
-Design goal updates:
-Next action:
-Evidence:
-```
-
-## Design Goal Update Rules
-
-- Add a goal only when it prevents a real failure mode or improves repeatable quality.
-- Prefer a small artifact or script over a large prose rule.
-- Keep hard prerequisites minimal; record optional adapters separately.
-- Turn recurring user corrections into audits, gates, or templates.
-- If a benchmark is tool-specific, extract the portable principle before adding it to GSE.
-- For non-trivial GSE changes, use `references/forward-test.md` to decide whether structural smoke, fixture forward test, or fresh-session forward test is required.
-
-## Current Known GSE Gaps
-
-- GSE has project scoring, bootstrap smoke, target doctor, command adapters, release gates, evidence taxonomy, quality gates, and final-form progress audits. Keep this section current when a gap is closed so future agents do not chase stale work.
-- Host adapter pointer templates are verified through `scripts/generate-command-adapter.mjs` and `scripts/audit-command-adapters.mjs`; older `generate-host-adapter.mjs` coverage is legacy fixture compatibility, not the preferred adoption route.
-- Remaining final-form gaps are owner/external evidence gates: public repository settings, public CI run, public security contact, registry publication, marketplace approval, native slash-command evidence, and other host runtime invocation.
-- Local future-hardening candidates should come from fresh benchmark evidence, not from this historical list.
+# Benchmark Audit
+
+Use this when improving GSE itself: changing the GSE skill, its scripts, templates, references, project scaffold, or development goals.
+
+## Purpose
+
+GSE development must proactively find workflow gaps. Do not wait for the user to discover missing requirements through manual testing.
+
+Run this audit against verified local skills, project files, tool help, official docs when available, and focused experiments. Label design judgments separately from verified facts.
+
+## Benchmark Sources
+
+Use the best available sources for the current host:
+
+- Local GSE files under `.gse/` or the skill folder.
+- Installed workflow skills: Comet, OpenSpec, Superpowers-style skills, agentic-engineering, subagent-driven-development, TDD, code review, self-improvement, QA, CI/CD.
+- Public or local skill repositories when explicitly referenced or already cloned, such as `mattpocock/skills`.
+- Project rules only when GSE is being tested inside a real project: `AGENTS.md`, `CLAUDE.md`, `CONTEXT.md`, ADRs, issue tracker docs, CI config, test scripts.
+- Official tool docs only when needed for a drift-prone claim.
+
+## GSE Development Audit Matrix
+
+Score each area as `missing`, `thin`, `usable`, or `strong`.
+
+| Area | Questions |
+|---|---|
+| Setup | Can a new agent install or initialize GSE without guessing? |
+| Router | Is there a clear map from user intent to GSE references, scripts, and modes? |
+| Goal Map | Are GSE's north star, current priority, risks, and next slice visible? |
+| Domain Model | Is shared language captured, challenged, and updated? |
+| Specs | Are GSE change outcome, scope, non-goals, contracts, and acceptance explicit? |
+| Task Slicing | Are tasks vertical, independently verifiable, and sized by risk? |
+| Tool Acceleration | Are search, LSP/index, browser, API, MCP, and CI tools recorded with fallbacks? |
+| Multi-Agent | Are roles, dispatch packets, file ownership, review gates, and no-fake-delegation rules clear? |
+| Implementation | Does GSE development preserve skill patterns and avoid unrelated expansion? |
+| Testing | Are focused tests, TDD, smoke, regression, and UI verification rules present? |
+| Review | Are spec compliance and code quality reviewed separately? |
+| Evidence | Is GSE change evidence recorded with commands and residual risk? |
+| Release | Are migration, rollout, rollback, smoke, and known-risk steps defined? |
+| Incident | Is there a path for failures, postmortems, and prevention gates? |
+| Learning | Are reusable lessons promoted into rules, gates, or templates? |
+| Context Hygiene | Are handoff, compaction, stale-context, and token-budget rules defined? |
+| Adapter Drift | Are host-specific GSE adapters prevented from diverging from the portable source of truth? |
+| Security | Are secrets, permissions, destructive tools, and external services bounded? |
+| Observability | Are traces, cost, retries, failures, and long-running state captured when relevant? |
+
+## Required Output
+
+```text
+Outcome:
+Benchmark sources:
+Strong areas:
+Gaps:
+Design goal updates:
+Next action:
+Evidence:
+```
+
+## Design Goal Update Rules
+
+- Add a goal only when it prevents a real failure mode or improves repeatable quality.
+- Prefer a small artifact or script over a large prose rule.
+- Keep hard prerequisites minimal; record optional adapters separately.
+- Turn recurring user corrections into audits, gates, or templates.
+- If a benchmark is tool-specific, extract the portable principle before adding it to GSE.
+- For non-trivial GSE changes, use `references/forward-test.md` to decide whether structural smoke, fixture forward test, or fresh-session forward test is required.
+
+## Current Known GSE Gaps
+
+- GSE has project scoring, bootstrap smoke, target doctor, command adapters, release gates, evidence taxonomy, quality gates, and final-form progress audits. Keep this section current when a gap is closed so future agents do not chase stale work.
+- Host adapter pointer templates are verified through `scripts/generate-command-adapter.mjs` and `scripts/audit-command-adapters.mjs`; older `generate-host-adapter.mjs` coverage is legacy fixture compatibility, not the preferred adoption route.
+- Remaining final-form gaps are owner/external evidence gates: public repository settings, public CI run, public security contact, registry publication, marketplace approval, native slash-command evidence, and other host runtime invocation.
+- Local future-hardening candidates should come from fresh benchmark evidence, not from this historical list.

package/references/community-channels.md

@@ -1,46 +1,46 @@
-# Community Channels
-
-Use this when a public GSE release needs owner-approved contribution, support, sponsorship, or service links.
-
-Community channels are release metadata. They help people find the right place to ask questions, support the maintainer, or discover related services. They do not prove package publication, marketplace approval, security disclosure readiness, or host-native command support.
-
-## Current Owner Candidate
-
-GateHub can be listed as an optional maintainer support and service link after owner approval:
-
-- Name: GateHub
-- URL: https://gatehub.top/
-- Public page title observed on 2026-07-07: `GateHub - AI API Gateway`
-- Public subtitle observed on 2026-07-07: `AI大模型代理平台`
-- Public contact observed on 2026-07-07: `QQ：275005746`
-- Recommended use in GSE docs: optional support, sponsorship, affiliate, or maintainer-service link.
-
-Do not describe GateHub as:
-
-- the official GSE package registry,
-- a marketplace approval channel,
-- a vulnerability disclosure channel,
-- proof of public CI, release, or host runtime support,
-- a required dependency for using GSE.
-
-## Placement
-
-Recommended locations:
-
-- `SUPPORT.md`: optional maintainer/community support channel.
-- Public repository sidebar or GitHub profile: project support or service link.
-- Release notes: optional "Support the maintainer" link when the release owner approves it.
-- Marketplace/catalog listing: support URL or related service URL, if the marketplace allows it.
-
-Avoid putting the link into the core workflow explanation, command reference, quality gates, or installation steps unless GateHub becomes a verified part of that workflow.
-
-## Acceptance
-
-A community channel can be called:
-
-- `result`: the link and intended use are documented.
-- `verified`: the link resolves and the docs preserve claim boundaries.
-- `accepted`: the owner approves the public placement and the target public page, repository, or listing contains the link.
-
-Keep security contact separate. A support or service contact is not a vulnerability disclosure policy unless the owner explicitly accepts it as such and `SECURITY.md` is updated.
-
+# Community Channels
+
+Use this when a public GSE release needs owner-approved contribution, support, sponsorship, or service links.
+
+Community channels are release metadata. They help people find the right place to ask questions, support the maintainer, or discover related services. They do not prove package publication, marketplace approval, security disclosure readiness, or host-native command support.
+
+## Current Owner Candidate
+
+GateHub can be listed as an optional maintainer support and service link after owner approval:
+
+- Name: GateHub
+- URL: https://gatehub.top/
+- Public page title observed on 2026-07-07: `GateHub - AI API Gateway`
+- Public subtitle observed on 2026-07-07: `AI大模型代理平台`
+- Public contact observed on 2026-07-07: `QQ：275005746`
+- Recommended use in GSE docs: optional support, sponsorship, affiliate, or maintainer-service link.
+
+Do not describe GateHub as:
+
+- the official GSE package registry,
+- a marketplace approval channel,
+- a vulnerability disclosure channel,
+- proof of public CI, release, or host runtime support,
+- a required dependency for using GSE.
+
+## Placement
+
+Recommended locations:
+
+- `SUPPORT.md`: optional maintainer/community support channel.
+- Public repository sidebar or GitHub profile: project support or service link.
+- Release notes: optional "Support the maintainer" link when the release owner approves it.
+- Marketplace/catalog listing: support URL or related service URL, if the marketplace allows it.
+
+Avoid putting the link into the core workflow explanation, command reference, quality gates, or installation steps unless GateHub becomes a verified part of that workflow.
+
+## Acceptance
+
+A community channel can be called:
+
+- `result`: the link and intended use are documented.
+- `verified`: the link resolves and the docs preserve claim boundaries.
+- `accepted`: the owner approves the public placement and the target public page, repository, or listing contains the link.
+
+Keep security contact separate. A support or service contact is not a vulnerability disclosure policy unless the owner explicitly accepts it as such and `SECURITY.md` is updated.
+

package/references/compatibility.md

@@ -1,70 +1,70 @@
-# Compatibility And Adoption Matrix
-
-Use this to record what GSE can honestly claim across agent hosts. This matrix is about GSE portability, not proof that every host-specific tool is installed in a project.
-
-## Status Vocabulary
-
-- `verified`: backed by a local file, script, fixture, command, or trusted project-specific evidence in the current GSE skill or target project.
-- `documented`: described by GSE references, examples, or project files, but not exercised in the current evidence set.
-- `unknown`: no reliable evidence yet.
-- `unavailable`: expected capability is missing or failed when checked.
-
-Never upgrade a host capability from `documented` to `verified` just because another host has a similar capability.
-
-## Portable Source Of Truth
-
-`.gse/` is the portable source of truth for goals, profile, quality gates, evidence, learning, and project-specific workflow rules.
-
-Host-specific folders are adapters. They may contain commands, hooks, skills, MCP notes, UI metadata, or short pointers, but they should point back to `.gse/` instead of copying the whole workflow.
-
-## Host Matrix
-
-| Host family | Adapter location | Source-of-truth pointer | Current status | Evidence | Fallback |
-|---|---|---|---|---|---|
-| Codex-style | `.codex/`, Codex skills, MCP config | Must point to `.gse/` | `verified` for fixture pointer; host tools are project-specific | `examples/agent-runtime-host/.codex/gse-adapter.md`, `scripts/forward-test-gse.mjs`, `scripts/audit-fixtures.mjs` | Use `SKILL.md`, `.gse/project-profile.md`, and markdown workflow when Codex host tools are absent |
-| Claude Code-style | `.claude/commands/`, `.claude/agents/`, `.claude/hooks/` | Must point to `.gse/` | `verified` for fixture pointer; commands/agents/hooks remain project-specific | `examples/agent-runtime-host/.claude/gse-adapter.md`, `scripts/forward-test-gse.mjs`, `scripts/audit-fixtures.mjs` | Use `.gse/` docs directly; do not duplicate goal maps into `.claude/` |
-| Hermes/AION-style runtime | `.gse/host-adapters/hermes-runtime.md`, runtime skills, worker adapters, memory/tool substrate docs | Must keep AION/product policy in `.gse/` or project docs; runtime details are adapters | `verified` for generated pointer; runtime tools remain project-specific | `scripts/generate-command-adapter.mjs`, `scripts/audit-command-adapters.mjs`, `references/host-adapters.md`, `references/model-routing.md`, `examples/agent-runtime-host/docs/model-routing.md` | Treat runtime capabilities as `unknown` until project evidence verifies workers, memory, tools, or model routing |
-| WorkBuddy/other IDE agents | `.gse/host-adapters/workbuddy.md`, local docs, plugin settings, task templates | Must point to `.gse/` | `verified` for generated pointer; IDE tools remain project-specific | `scripts/generate-command-adapter.mjs`, `scripts/audit-command-adapters.mjs`, `SKILL.md`, `references/host-adapters.md` | Use `.gse/README.md`, `.gse/project-profile.md`, and `references/router.md` when no host adapter exists |
-| Copilot/Gemini-style assistants | repository instructions, workspace docs | Short instruction to read `.gse/project-profile.md` and relevant gates | `documented` | `references/host-adapters.md` | Use repository instructions plus `.gse/` files; keep advanced tool claims `unknown` |
-| Unknown or custom host | `.gse/host-adapters/generic-agent.md`, host-specific docs decided by the project | Must link back to `.gse/` | `verified` for generated generic pointer; host runtime remains unknown | `scripts/generate-command-adapter.mjs`, `scripts/audit-command-adapters.mjs` | Create a fuller adapter from `assets/templates/host-adapter.md` only when the project has a real host mechanism |
-
-## Capability Matrix
-
-| Capability | Portable GSE layer | Codex-style | Claude Code-style | Hermes/AION-style | WorkBuddy/other | Notes |
-|---|---|---|---|---|---|---|
-| Goal map and evidence | `verified` | `documented` | `documented` | `documented` | `documented` | Portable files live under `.gse/`; host adapters should point there |
-| Project bootstrap | `verified` | `documented` | `documented` | `documented` | `documented` | Verified by `scripts/audit-project.mjs` and `scripts/validate-gse.mjs` |
-| Project profile discovery | `verified` | `documented` | `documented` | `documented` | `documented` | Verified by `scripts/audit-adoption.mjs`; host use still depends on project files |
-| Host adapter pointer | `verified` for generated pointers | `verified` | `verified` | `verified` for generated pointer | `verified` for generated pointer | Generated pointers are verified by `scripts/audit-command-adapters.mjs`; runtime invocation still needs host records |
-| Subagents | `documented` fallback rules | `unknown` | `unknown` | `unknown` | `unknown` | Real subagent availability must be checked per host/session |
-| MCP | `documented` status vocabulary | `unknown` | `unknown` | `unknown` | `unknown` | Config presence is documented, not tool availability |
-| LSP/index | `documented` recommendation | `unknown` | `unknown` | `unknown` | `unknown` | Verify per project before relying on symbol navigation |
-| Browser/Playwright | `documented` evidence rules | `unknown` | `unknown` | `unknown` | `unknown` | Fixture config can document Playwright; running browser tests is separate evidence |
-| Model routing | `documented` reference | `unknown` | `unknown` | `documented` | `unknown` | Provider/model behavior needs provider-specific evidence |
-| Hooks/plugins | `documented` adapter rule | `unknown` | `unknown` | `unknown` | `unknown` | Do not enable hooks or plugins without project approval and evidence |
-
-## Adoption Rules
-
-1. Start from `.gse/README.md`, `.gse/project-profile.md`, and `.gse/goal-map.md` when they exist.
-2. If a host folder exists, read only the short host adapter first, then return to `.gse/` for policy and evidence.
-3. Record host-specific commands, hooks, MCP servers, subagents, models, browser tools, and indexes as `unknown` until checked in that project/session.
-4. Use `documented` for config or docs that exist but have not been executed.
-5. Use `verified` only when current evidence proves the claim.
-6. Use `unavailable` when an expected host feature is missing or failing.
-7. Use `references/drift-audit.md` when host folders and `.gse/` disagree.
-
-## Minimum Host Adapter
-
-A host adapter should be short:
-
-```text
-# <Host> Adapter
-
-Source of truth: `.gse/`.
-
-- Read `.gse/project-profile.md` before using host-specific tools.
-- Mark host capabilities verified only after current-session evidence.
-- Use `references/drift-audit.md` when adapter claims and current tools disagree.
-```
-
-Use `assets/templates/host-adapter.md` when a fuller adapter record is needed.
+# Compatibility And Adoption Matrix
+
+Use this to record what GSE can honestly claim across agent hosts. This matrix is about GSE portability, not proof that every host-specific tool is installed in a project.
+
+## Status Vocabulary
+
+- `verified`: backed by a local file, script, fixture, command, or trusted project-specific evidence in the current GSE skill or target project.
+- `documented`: described by GSE references, examples, or project files, but not exercised in the current evidence set.
+- `unknown`: no reliable evidence yet.
+- `unavailable`: expected capability is missing or failed when checked.
+
+Never upgrade a host capability from `documented` to `verified` just because another host has a similar capability.
+
+## Portable Source Of Truth
+
+`.gse/` is the portable source of truth for goals, profile, quality gates, evidence, learning, and project-specific workflow rules.
+
+Host-specific folders are adapters. They may contain commands, hooks, skills, MCP notes, UI metadata, or short pointers, but they should point back to `.gse/` instead of copying the whole workflow.
+
+## Host Matrix
+
+| Host family | Adapter location | Source-of-truth pointer | Current status | Evidence | Fallback |
+|---|---|---|---|---|---|
+| Codex-style | `.codex/`, Codex skills, MCP config | Must point to `.gse/` | `verified` for fixture pointer; host tools are project-specific | `examples/agent-runtime-host/.codex/gse-adapter.md`, `scripts/forward-test-gse.mjs`, `scripts/audit-fixtures.mjs` | Use `SKILL.md`, `.gse/project-profile.md`, and markdown workflow when Codex host tools are absent |
+| Claude Code-style | `.claude/commands/`, `.claude/agents/`, `.claude/hooks/` | Must point to `.gse/` | `verified` for fixture pointer; commands/agents/hooks remain project-specific | `examples/agent-runtime-host/.claude/gse-adapter.md`, `scripts/forward-test-gse.mjs`, `scripts/audit-fixtures.mjs` | Use `.gse/` docs directly; do not duplicate goal maps into `.claude/` |
+| Hermes/AION-style runtime | `.gse/host-adapters/hermes-runtime.md`, runtime skills, worker adapters, memory/tool substrate docs | Must keep AION/product policy in `.gse/` or project docs; runtime details are adapters | `verified` for generated pointer; runtime tools remain project-specific | `scripts/generate-command-adapter.mjs`, `scripts/audit-command-adapters.mjs`, `references/host-adapters.md`, `references/model-routing.md`, `examples/agent-runtime-host/docs/model-routing.md` | Treat runtime capabilities as `unknown` until project evidence verifies workers, memory, tools, or model routing |
+| WorkBuddy/other IDE agents | `.gse/host-adapters/workbuddy.md`, local docs, plugin settings, task templates | Must point to `.gse/` | `verified` for generated pointer; IDE tools remain project-specific | `scripts/generate-command-adapter.mjs`, `scripts/audit-command-adapters.mjs`, `SKILL.md`, `references/host-adapters.md` | Use `.gse/README.md`, `.gse/project-profile.md`, and `references/router.md` when no host adapter exists |
+| Copilot/Gemini-style assistants | repository instructions, workspace docs | Short instruction to read `.gse/project-profile.md` and relevant gates | `documented` | `references/host-adapters.md` | Use repository instructions plus `.gse/` files; keep advanced tool claims `unknown` |
+| Unknown or custom host | `.gse/host-adapters/generic-agent.md`, host-specific docs decided by the project | Must link back to `.gse/` | `verified` for generated generic pointer; host runtime remains unknown | `scripts/generate-command-adapter.mjs`, `scripts/audit-command-adapters.mjs` | Create a fuller adapter from `assets/templates/host-adapter.md` only when the project has a real host mechanism |
+
+## Capability Matrix
+
+| Capability | Portable GSE layer | Codex-style | Claude Code-style | Hermes/AION-style | WorkBuddy/other | Notes |
+|---|---|---|---|---|---|---|
+| Goal map and evidence | `verified` | `documented` | `documented` | `documented` | `documented` | Portable files live under `.gse/`; host adapters should point there |
+| Project bootstrap | `verified` | `documented` | `documented` | `documented` | `documented` | Verified by `scripts/audit-project.mjs` and `scripts/validate-gse.mjs` |
+| Project profile discovery | `verified` | `documented` | `documented` | `documented` | `documented` | Verified by `scripts/audit-adoption.mjs`; host use still depends on project files |
+| Host adapter pointer | `verified` for generated pointers | `verified` | `verified` | `verified` for generated pointer | `verified` for generated pointer | Generated pointers are verified by `scripts/audit-command-adapters.mjs`; runtime invocation still needs host records |
+| Subagents | `documented` fallback rules | `unknown` | `unknown` | `unknown` | `unknown` | Real subagent availability must be checked per host/session |
+| MCP | `documented` status vocabulary | `unknown` | `unknown` | `unknown` | `unknown` | Config presence is documented, not tool availability |
+| LSP/index | `documented` recommendation | `unknown` | `unknown` | `unknown` | `unknown` | Verify per project before relying on symbol navigation |
+| Browser/Playwright | `documented` evidence rules | `unknown` | `unknown` | `unknown` | `unknown` | Fixture config can document Playwright; running browser tests is separate evidence |
+| Model routing | `documented` reference | `unknown` | `unknown` | `documented` | `unknown` | Provider/model behavior needs provider-specific evidence |
+| Hooks/plugins | `documented` adapter rule | `unknown` | `unknown` | `unknown` | `unknown` | Do not enable hooks or plugins without project approval and evidence |
+
+## Adoption Rules
+
+1. Start from `.gse/README.md`, `.gse/project-profile.md`, and `.gse/goal-map.md` when they exist.
+2. If a host folder exists, read only the short host adapter first, then return to `.gse/` for policy and evidence.
+3. Record host-specific commands, hooks, MCP servers, subagents, models, browser tools, and indexes as `unknown` until checked in that project/session.
+4. Use `documented` for config or docs that exist but have not been executed.
+5. Use `verified` only when current evidence proves the claim.
+6. Use `unavailable` when an expected host feature is missing or failing.
+7. Use `references/drift-audit.md` when host folders and `.gse/` disagree.
+
+## Minimum Host Adapter
+
+A host adapter should be short:
+
+```text
+# <Host> Adapter
+
+Source of truth: `.gse/`.
+
+- Read `.gse/project-profile.md` before using host-specific tools.
+- Mark host capabilities verified only after current-session evidence.
+- Use `references/drift-audit.md` when adapter claims and current tools disagree.
+```
+
+Use `assets/templates/host-adapter.md` when a fuller adapter record is needed.

package/references/design-basis.md

@@ -1,38 +1,38 @@
-# GSE Design Basis
-
-This file separates verified sources from design judgment.
-
-## Verified Local Sources
-
-- `skill-creator` requires a concise `SKILL.md`, optional `references/`, `scripts/`, and `assets/`, with progressive disclosure and validation.
-- `agentic-engineering` defines eval-first execution, agent-sized decomposition, model routing, and review focus for AI-generated code.
-- `subagent-driven-development` defines fresh subagents per task, explicit roles, spec review, code quality review, and never faking delegation.
-- `comet` combines OpenSpec and Superpowers through open, design, build, verify, archive phases, with hotfix/tweak presets and state files.
-- `openspec-propose` creates proposal, design, specs, and tasks as change artifacts.
-- `self-improvement` records reusable learnings, errors, feature requests, and promotes recurring lessons into project rules.
-- `ci-cd-and-automation` and `code-review-and-quality` describe automated gates and review axes as quality enforcement mechanisms.
-
-## User Requirements Captured
-
-- GSE must target large, long-running commercial projects first, while degrading for small projects.
-- GSE must be agent-agnostic across Codex, Claude Code, Hermes, WorkBuddy, and similar tools.
-- GSE must support goal maps, specs, evidence, roles, tool acceleration, learning, release, incident, and quality gates.
-- GSE must have few hard prerequisites; optional tools should enhance, not block.
-- GSE itself must be developed using GSE principles.
-- GSE must not invent unsupported facts; evidence and assumptions must be separated.
-- GSE must proactively benchmark itself and project workflows against mature skills and public practices, then convert gaps into goals, gates, templates, or scripts.
-
-## Design Judgments
-
-- Use GSE as the public name because it is short, avoids AES encryption ambiguity, and captures the core loop.
-- Use `.gse/` as the durable project folder because hidden workflow folders are familiar and avoid polluting product docs.
-- Use task levels so small tasks do not inherit enterprise ceremony.
-- Use markdown fallback for all optional tools so the workflow remains portable.
-- Use benchmark audits as a recurring design mechanism because a purely reactive process lets users discover missing requirements through failures.
-
-## Open Questions
-
-- Whether GSE should later publish official adapters for specific hosts, such as Codex Desktop or Claude Code.
-- Whether GSE should include a telemetry dashboard by default or only recommend skill-usage as an optional enhancement.
-- Whether project initialization should update `AGENTS.md` automatically or require explicit approval.
-- How often benchmark audits should run by default: every major project phase, every N slices, or only on explicit request.
+# GSE Design Basis
+
+This file separates verified sources from design judgment.
+
+## Verified Local Sources
+
+- `skill-creator` requires a concise `SKILL.md`, optional `references/`, `scripts/`, and `assets/`, with progressive disclosure and validation.
+- `agentic-engineering` defines eval-first execution, agent-sized decomposition, model routing, and review focus for AI-generated code.
+- `subagent-driven-development` defines fresh subagents per task, explicit roles, spec review, code quality review, and never faking delegation.
+- `comet` combines OpenSpec and Superpowers through open, design, build, verify, archive phases, with hotfix/tweak presets and state files.
+- `openspec-propose` creates proposal, design, specs, and tasks as change artifacts.
+- `self-improvement` records reusable learnings, errors, feature requests, and promotes recurring lessons into project rules.
+- `ci-cd-and-automation` and `code-review-and-quality` describe automated gates and review axes as quality enforcement mechanisms.
+
+## User Requirements Captured
+
+- GSE must target large, long-running commercial projects first, while degrading for small projects.
+- GSE must be agent-agnostic across Codex, Claude Code, Hermes, WorkBuddy, and similar tools.
+- GSE must support goal maps, specs, evidence, roles, tool acceleration, learning, release, incident, and quality gates.
+- GSE must have few hard prerequisites; optional tools should enhance, not block.
+- GSE itself must be developed using GSE principles.
+- GSE must not invent unsupported facts; evidence and assumptions must be separated.
+- GSE must proactively benchmark itself and project workflows against mature skills and public practices, then convert gaps into goals, gates, templates, or scripts.
+
+## Design Judgments
+
+- Use GSE as the public name because it is short, avoids AES encryption ambiguity, and captures the core loop.
+- Use `.gse/` as the durable project folder because hidden workflow folders are familiar and avoid polluting product docs.
+- Use task levels so small tasks do not inherit enterprise ceremony.
+- Use markdown fallback for all optional tools so the workflow remains portable.
+- Use benchmark audits as a recurring design mechanism because a purely reactive process lets users discover missing requirements through failures.
+
+## Open Questions
+
+- Whether GSE should later publish official adapters for specific hosts, such as Codex Desktop or Claude Code.
+- Whether GSE should include a telemetry dashboard by default or only recommend skill-usage as an optional enhancement.
+- Whether project initialization should update `AGENTS.md` automatically or require explicit approval.
+- How often benchmark audits should run by default: every major project phase, every N slices, or only on explicit request.