@t275005746/gse 0.1.0

package/references/commands.md

@@ -0,0 +1,295 @@
+# GSE Commands
+
+Use this when the user writes `/gse ...`, `gse: ...`, or asks for command-style GSE usage.
+
+These are host-neutral command semantics. They define what an agent should do. They do not prove that the current host has native slash-command support. If the host supports custom slash commands, host adapters may map these commands to native entries. If not, treat the text command as an instruction and execute the matching route.
+
+Portable adapter helper:
+
+```text
+node <gse-skill>/scripts/generate-command-adapter.mjs --target <project-root> --host claude|codex|hermes|workbuddy|copilot|gemini|generic|all
+```
+
+Portable execution helper:
+
+```text
+node <gse-skill>/scripts/gse.mjs continue --target <project-root>
+node <gse-skill>/scripts/run-gse-command.mjs --target <project-root> --command "/gse continue"
+node <gse-skill>/scripts/run-gse-command.mjs --target <gse-skill> --command "/gse owner-actions" --json --compact
+node <gse-skill>/scripts/run-gse-command.mjs --target <gse-skill> --command "/gse probe --public-repo-url __PUBLIC_REPO_URL__" --json
+node <gse-skill>/scripts/run-gse-command.mjs --target <gse-skill> --command "/gse package" --json
+node <gse-skill>/scripts/run-gse-command.mjs --target <gse-skill> --command "/gse install --source __PACKAGE_DIR__ --install-target __INSTALL_SKILL_DIR__" --json
+node <gse-skill>/scripts/run-gse-command.mjs --target <gse-skill> --command "/gse public-release" --json
+node <gse-skill>/scripts/run-gse-command.mjs --target <project-root> --command "/gse learn --summary __LESSON__" --execute --json
+```
+
+Validation profile helper:
+
+```text
+node <gse-skill>/scripts/run-validation-profile.mjs --target <project-root> --profile lite|standard|enterprise|release
+```
+
+Portable command execution audit:
+
+```text
+node <gse-skill>/scripts/audit-command-execution.mjs --root <gse-skill> --profile lite|full
+```
+
+The Claude adapter writes `.claude/commands/gse.md`, matching Claude Code's documented project command shape. The Codex adapter writes a pointer file because project-level native `/gse` command files are not verified for Codex in this package. Hermes, WorkBuddy, Copilot, Gemini, and generic adapters write portable pointer files only; they do not prove host runtime invocation.
+
+## Command Map
+
+| Command | Purpose | Primary Route | Required Inputs | Typical Verification |
+|---|---|---|---|---|
+| `/gse help` | Show available GSE commands and the current project entry files | Command help | `SKILL.md`, `references/commands.md` | none or file inspection |
+| `/gse init` | Initialize `.gse/` in a new project | Project bootstrap | project rules, `project-bootstrap.md` | scaffold file check |
+| `/gse adopt` | Adopt GSE in an existing project without overwriting local rules | Project adoption | project rules, `adoption-recipes.md`, `project-profile.md` | discovery or adoption smoke |
+| `/gse continue` | Continue the current project from its goal map or canonical plan | Execute workflow | project rules, `.gse/project-profile.md`, goal map or canonical plan | focused test/smoke for the slice |
+| `/gse status` | Show current project state; for the GSE skill, show final-form progress and remaining public/host blockers | Status workflow | `.gse/state.json`; for GSE skill, final readiness audits | state/report inspection |
+| `/gse doctor` | Diagnose public/host acceptance blockers for the GSE skill, or target-project GSE readiness for normal projects | Final acceptance or project doctor | final readiness matrix, `.gse/state.json`, project profile | public acceptance doctor or target project doctor |
+| `/gse acceptance` | Alias for `/gse doctor` when the user wants final acceptance boundaries | Final acceptance doctor | final readiness matrix and owner/external evidence records | public acceptance doctor |
+| `/gse owner-actions` | Show the remaining owner/external actions required before the GSE skill can claim public acceptance | Owner/external action packet | final readiness matrix and public acceptance doctor | owner action command smoke |
+| `/gse probe` | Probe supplied owner/external evidence locations before accepted records are written | Public external gate probe | public repo/security/CI/registry/marketplace/host evidence inputs | public external gate probe audit |
+| `/gse release` | Dry-run or generate the GSE release bundle for open-source/package handoff | Release bundle workflow | release metadata, package snapshot, acceptance handoff, owner/external kit | release bundle audit |
+| `/gse package` | Dry-run or generate a local installable GSE package | Package workflow | package label and output directory | package manifest or distribution audit |
+| `/gse install` | Dry-run or install GSE from a local package path or URL-shaped package source | Install workflow | package source and install target | install dry-run or installed CLI smoke |
+| `/gse public-release` | Dry-run or generate the ordered public release checklist for owner execution | Public release checklist workflow | release status manifest and pending owner/external gates | public release checklist audit |
+| `/gse change` | Create or normalize a GSE change spec pack | Spec workflow | change id, task level, goal map | change folder structure check |
+| `/gse slice` | Define or normalize outcome, scope, acceptance, evidence, risk, and next action | Spec workflow | `goal-map.md`, `spec-workflow.md`, `quality-gates.md` | structural check |
+| `/gse verify` | Run the smallest verification that proves the current slice | Verification gate | `quality-gates.md`, project profile, evidence taxonomy | focused test/API/browser smoke |
+| `/gse learn` | Record a reusable lesson in `.gse/learnings.md` | Learning workflow | summary, trigger, source, optional impact | learning command audit |
+| `/gse audit` | Check workflow drift, stale claims, missing evidence, or too-heavy process | Audit workflow | `benchmark-audit.md`, `drift-audit.md`, project profile | audit script or checklist |
+| `/gse close` | Check whether the current slice is ready to close | Close readiness check | `.gse/state.json`, evidence index, quality gates | close gate audit |
+
+## Aliases
+
+- `gse help` -> `/gse help`
+- `gse init` -> `/gse init`
+- `gse adopt` -> `/gse adopt`
+- `gse continue` -> `/gse continue`
+- `gse next` -> `/gse continue`
+- `gse status` -> `/gse status`
+- `gse doctor` -> `/gse doctor`
+- `gse acceptance` -> `/gse acceptance`
+- `gse owner-actions` -> `/gse owner-actions`
+- `gse owner` -> `/gse owner-actions`
+- `gse probe` -> `/gse probe`
+- `gse release` -> `/gse release`
+- `gse package` -> `/gse package`
+- `gse install` -> `/gse install`
+- `gse public-release` -> `/gse public-release`
+- `gse change` -> `/gse change`
+- `gse spec` -> `/gse change`
+- `gse slice` -> `/gse slice`
+- `gse verify` -> `/gse verify`
+- `gse learn` -> `/gse learn`
+- `gse audit` -> `/gse audit`
+- `gse close` -> `/gse close`
+
+## Usage Examples
+
+```text
+/gse continue AION
+```
+
+Expected behavior:
+
+1. Enter the project root.
+2. Read project rules, `.gse/state.json`, and `.gse/project-profile.md`.
+3. Read the project's canonical plan when one is declared.
+4. Pick the next verifiable slice from the machine-readable state plus goal map.
+5. Execute, verify, record evidence, update `.gse/state.json` and `.gse/evidence/index.jsonl`, and close only when accepted by the applicable gate.
+
+Portable helper:
+
+```text
+node <gse-skill>/scripts/generate-session-prompt.mjs --target <project-root>
+```
+
+For existing projects that have `.gse/` but do not yet have machine-readable continuation files:
+
+```text
+node <gse-skill>/scripts/update-project-state.mjs --target <project-root>
+```
+
+```text
+/gse init --mode standard
+```
+
+Expected behavior:
+
+1. Inspect existing project rules first.
+2. Create `.gse/` if missing.
+3. Preserve existing project-specific rules.
+4. Run a scaffold or structure check.
+
+```text
+/gse change add-user-login --level standard
+```
+
+Expected behavior:
+
+1. Create `.gse/changes/add-user-login/`.
+2. Add `brief.md`, `spec.md`, `design.md`, `tasks.md`, `evidence.md`, `review.md`, and `execution-quality-pack.md`.
+3. Keep OpenSpec and Superpowers optional: use them when available, otherwise use the GSE markdown pack.
+4. Do not overwrite existing change files unless explicitly forced.
+
+Portable helper:
+
+```text
+node <gse-skill>/scripts/init-change.mjs --target <project-root> --change-id add-user-login --level standard
+```
+
+```text
+/gse verify --profile lite
+```
+
+Expected behavior:
+
+1. Select a validation profile from `lite`, `standard`, `enterprise`, or `release`.
+2. Run `scripts/run-validation-profile.mjs` with that profile.
+3. Keep release/distribution-heavy checks out of `lite` and `standard` unless the selected profile requires them.
+4. Report skipped heavy gates as a deliberate profile boundary, not as hidden success.
+5. Use the lite command execution audit for routine command coverage; reserve the full command execution audit for release-grade confidence.
+
+```text
+/gse audit
+```
+
+Expected behavior:
+
+1. Check whether project rules, `.gse/`, goal map, quality gates, tooling, and evidence are aligned.
+2. Report gaps as `missing`, `weak`, `verified`, or `accepted`.
+3. Do not fix unrelated project code unless explicitly asked.
+
+```text
+/gse learn --summary "Prefer UTF-8 safe readers for Chinese docs before judging mojibake" --trigger "encoding review" --source "project slice"
+```
+
+Expected behavior:
+
+1. Dry-run the learning entry by default and show the target `.gse/learnings.md` path.
+2. Require `--summary`; accept optional `--trigger`, `--source`, `--impact`, and `--promotion`.
+3. Append the entry only when `--execute` is supplied.
+4. Skip duplicate summaries instead of appending repeated lessons.
+5. Keep raw chain-of-thought, long logs, and temporary attempts out of learnings.
+
+```text
+/gse status
+```
+
+Expected behavior:
+
+1. For normal projects, read `.gse/state.json` and show phase, current slice, next action, and declared project files.
+2. For the GSE skill package itself, run the final-form progress report in dry-run mode and show local engineering readiness, full final-form readiness, pending owner/external gates, and `publicAccepted`.
+3. Do not treat status output as completion evidence unless the relevant gate audit is also recorded.
+
+```text
+/gse doctor
+```
+
+Expected behavior:
+
+1. For the GSE skill package, run the public acceptance doctor and list remaining owner/external blockers with concrete record commands.
+2. For normal target projects, run the target project doctor and report `.gse/` readiness, canonical plan visibility, evidence state, and host adapter drift.
+3. Keep owner-required and external-required gates explicit. Do not convert local mechanics into public acceptance.
+
+```text
+/gse owner-actions
+```
+
+Expected behavior:
+
+1. For the GSE skill package itself, return a compact owner/external action list from the public acceptance doctor.
+2. Include the pending gate count, responsible party, required evidence, record command, and dry-run preflight command for each gate.
+3. Prefer `--json --compact` when handing the action list to a project owner or maintainer; compact mode returns only the owner action packet without local runner diagnostics.
+4. Keep the output as a collection checklist. It does not publish, approve, configure, or accept anything by itself.
+5. For normal projects, use `/gse doctor` instead; `/gse owner-actions` is only for the GSE skill's public/host final-form gates.
+
+```text
+/gse probe --public-repo-url __PUBLIC_REPO_URL__
+```
+
+Expected behavior:
+
+1. For the GSE skill package itself, run `scripts/probe-public-external-gates.mjs`.
+2. Accept only explicit evidence input flags such as `--public-repo-url`, `--security-contact-url`, `--public-ci-run-url`, `--registry-package-url`, `--marketplace-url`, `--native-host-evidence`, and `--other-host-evidence`.
+3. Return `waiting-for-input` when no evidence inputs are supplied.
+4. Reject placeholder, example, local, or missing evidence before accepted records are written.
+5. Keep the output as a preflight. It does not publish, approve, configure, or accept anything by itself.
+
+```text
+/gse release
+```
+
+Expected behavior:
+
+1. For the GSE skill package itself, dry-run `scripts/generate-release-bundle.mjs`.
+2. Report release bundle readiness, validation summary, and public acceptance boundary without writing the canonical bundle.
+3. Accept optional `--label` and `--out` values for release-bundle naming and output routing.
+4. Only write a bundle when the command is run with `--execute`.
+5. Keep the output as release handoff preparation. It does not publish a package, approve a marketplace listing, configure a repository, or mark public acceptance complete.
+
+```text
+/gse package
+```
+
+Expected behavior:
+
+1. For the GSE skill package itself, dry-run `scripts/package-gse.mjs`.
+2. Report package readiness, intended output, file count, and manifest path without writing package files.
+3. Accept optional `--label` and `--out` values for package naming and output routing.
+4. Only write a package when the command is run with `--execute`.
+5. Keep the output as local packaging evidence. It does not publish to a registry or mark public acceptance complete.
+
+```text
+/gse install --source __PACKAGE_DIR__ --install-target __INSTALL_SKILL_DIR__
+```
+
+Expected behavior:
+
+1. For the GSE skill package itself, dry-run `scripts/install-gse.mjs`.
+2. Accept `--source <package-dir>` or `--source-url <file-or-http-package-url>`.
+3. Use `--install-target <install-skill-dir>` for the destination so it does not conflict with the command runner's own `--target <gse-root>`.
+4. Only write the install target when the command is run with `--execute`.
+5. Keep the output as local or URL-shaped installability evidence. It does not publish to a registry, approve a marketplace listing, or prove global host installation.
+
+```text
+/gse public-release
+```
+
+Expected behavior:
+
+1. For the GSE skill package itself, dry-run `scripts/generate-public-release-checklist.mjs`.
+2. Show the ordered public release checklist covering repository settings, security contact, public CI, registry publication, marketplace listing, native slash-command evidence, other host runtime evidence, and final verification.
+3. Accept optional `--out` and `--manifest` values for checklist output routing.
+4. Only write a checklist when the command is run with `--execute`.
+5. Keep the output as an owner execution runway. It does not publish, approve, configure, or accept anything by itself.
+
+## Host Adapter Rules
+
+- Do not claim native slash-command support unless the current host exposes it and it was verified.
+- Do not treat generated pointer files as runtime proof; run the host or a host-specific smoke before claiming the command executes natively.
+- Record real UI, slash-command, command-palette, plugin, or background-thread invocation with `scripts/record-host-invocation.mjs` or `assets/templates/host-ui-invocation-record.md`; validate a completed record with `scripts/audit-host-ui-invocation.mjs --record <file>` and aggregate persistent host records with `scripts/audit-host-runtime-invocations.mjs`.
+- For Codex, Claude Code, Hermes/AION-style runtimes, WorkBuddy, or future hosts, map native command files back to this reference instead of duplicating all policy.
+- If a host has no slash-command mechanism, the text command still works as a natural-language trigger for the skill.
+- Keep command output short and route to the relevant reference file instead of loading every GSE document.
+
+## Completion Rules
+
+- `/gse continue`, `/gse verify`, and `/gse close` must preserve the result -> verified -> accepted distinction.
+- `/gse close` is read-only in the portable command runner. It cannot mark a slice complete, archive a change, or write evidence by itself.
+- Portable close check:
+
+```text
+node <gse-skill>/scripts/audit-close-gate.mjs --target <project-root>
+```
+
+- To archive a named change pack after evidence exists, use the explicit change lifecycle script:
+
+```text
+node <gse-skill>/scripts/close-change.mjs --target <project-root> --change-id <change-id> --status result|verified|accepted --json
+```
+
+- `/gse audit` cannot certify arbitrary repositories unless project-specific checks ran.
+- `/gse init` and `/gse adopt` cannot overwrite existing project workflow files without explicit owner approval or `--force` with a recorded reason.

package/references/community-channels.md

@@ -0,0 +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.
+

package/references/compatibility.md

@@ -0,0 +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.

package/references/design-basis.md

@@ -0,0 +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.

package/references/domain-model.md

@@ -0,0 +1,129 @@
+# Domain Model
+
+Use this when GSE needs to consume or update a project's domain language, glossary, context files, or ADRs.
+
+## Purpose
+
+Long-running agent work fails when project language drifts. GSE keeps a small domain model layer so future agents can use the project's own words instead of rediscovering or renaming concepts every session.
+
+## Source Files
+
+Read these in order when relevant:
+
+1. `.gse/project-profile.md` for the project identity and known docs.
+2. `CONTEXT.md` for a single-context project glossary.
+3. `CONTEXT-MAP.md` for monorepos or multi-domain projects.
+4. `docs/adr/` or context-specific ADR folders for decisions.
+5. Product specs only after glossary/ADR context is understood.
+
+Do not read all context files in a large monorepo. Use `CONTEXT-MAP.md` or project-profile evidence to pick the relevant context.
+
+## File Roles
+
+| File | Purpose | Should Not Contain |
+|---|---|---|
+| `.gse/project-profile.md` | Short project identity, commands, tools, gates, and doc map | Full glossary, implementation specs, large logs |
+| `CONTEXT.md` | Domain glossary and ubiquitous language | Implementation details, task lists, transient notes |
+| `CONTEXT-MAP.md` | Map from subsystem/domain to its context and ADR files | Detailed definitions that belong in each context |
+| `docs/adr/*.md` | Durable architectural or product decisions | Ordinary implementation notes or temporary preferences |
+| `.gse/changes/*` | Current change outcome, scope, acceptance, evidence | Canonical domain definitions |
+
+## Single-Context Project
+
+Use one root `CONTEXT.md` when the project has one dominant domain language.
+
+```text
+project/
+  CONTEXT.md
+  docs/adr/
+  .gse/project-profile.md
+```
+
+`CONTEXT.md` should define terms like:
+
+- Canonical term.
+- Meaning in this project.
+- Terms not to use.
+- Important relationships to other terms.
+- A short example scenario when it prevents ambiguity.
+
+## Multi-Context Project
+
+Use `CONTEXT-MAP.md` when one glossary would mix unrelated domains.
+
+```text
+project/
+  CONTEXT-MAP.md
+  apps/admin/CONTEXT.md
+  services/billing/CONTEXT.md
+  services/billing/docs/adr/
+  docs/adr/
+```
+
+`CONTEXT-MAP.md` should map:
+
+- Context name.
+- Path to context file.
+- Related code paths.
+- Related ADR path.
+- Owner or review expectation when known.
+
+## When To Update The Domain Model
+
+Update domain files only when the change is durable:
+
+- A term is ambiguous, overloaded, or repeatedly explained.
+- The user resolves a naming conflict.
+- Code and user language disagree about a domain concept.
+- A new durable product concept is introduced.
+- A future agent would likely make a wrong assumption without the note.
+
+Do not update domain files for:
+
+- Temporary implementation details.
+- One-off task notes.
+- Test fixtures that are not domain examples.
+- Preferences that belong in project profile or quality gates.
+
+## ADR Boundary
+
+Create or suggest an ADR only when all are true:
+
+1. Hard to reverse: changing later has meaningful cost.
+2. Surprising without context: future agents or maintainers would ask why.
+3. Real trade-off: there were plausible alternatives.
+
+If any condition is missing, record the fact in the change evidence or project profile instead of creating an ADR.
+
+## Conflict Handling
+
+If project language conflicts:
+
+1. Quote the conflicting sources by path.
+2. Do not silently choose one.
+3. Ask or propose the smallest resolution.
+4. Record the resolved canonical term in the right context file.
+5. If the resolution is hard to reverse and surprising, create or propose an ADR.
+
+## GSE Integration
+
+- `project-profile.md` points agents to the relevant context and ADR files.
+- `spec-workflow.md` should use canonical domain terms from context files.
+- `quality-gates.md` can require domain-language checks for high-risk changes.
+- `evidence-taxonomy.md` still decides whether the domain update is result, verified, or accepted.
+
+## Evidence Examples
+
+Result:
+
+- Added a new glossary entry to `CONTEXT.md`.
+
+Verified:
+
+- Checked the changed spec and code references use the canonical term.
+- Confirmed no conflicting term remains in touched files.
+
+Accepted:
+
+- User, domain owner, reviewer, or policy accepts the new canonical term.
+

package/references/domain-quality-gates.md

@@ -0,0 +1,75 @@
+# Domain Quality Gates
+
+Use this when a task has domain risk beyond basic file or script correctness. Pick only the gates that match the changed behavior and project risk.
+
+This reference is risk-based. Lite work should not inherit every gate by default. Commercial, user-visible, data-bearing, security-sensitive, release, or long-running work should receive stronger gates.
+
+## Selection Rule
+
+Choose gates by asking:
+
+1. What could fail for users, data, operators, maintainers, or future agents?
+2. Which project files, tests, commands, docs, or runtime checks can prove the risk is controlled?
+3. Is the evidence `result`, `verified`, or `accepted` according to `references/evidence-taxonomy.md`?
+4. Is a tool merely documented, or was it actually run in this project/session?
+
+Do not claim scan, benchmark, browser, accessibility, security, or resilience results unless the relevant command or inspection was actually executed.
+
+## Scale Guidance
+
+| Level | Default domain gate weight |
+|---|---|
+| Lite | Use only the directly relevant gate and one focused evidence point. |
+| Standard | Use relevant domain gates plus regression or smoke evidence. |
+| Enterprise | Use a risk matrix, review axis, release/recovery path, and project-specific evidence. |
+
+Upgrade the gate weight when a change touches public APIs, user data, auth, payments, model/provider routing, migrations, release, cross-module state, worker orchestration, browser automation, or main-path UX.
+
+## Gate Matrix
+
+| Domain | Trigger | Minimum evidence | Escalate when |
+|---|---|---|---|
+| Security/privacy | Secrets, auth, permissions, user data, provider payloads, MCP/tools, browser traces, logs | Secret scan or file inspection, permission boundary review, no raw secrets/provider payloads in committed or user-visible output | Data exposure, auth bypass, destructive tools, public release, external services |
+| Performance/cost | Latency, heavy context loading, loops, model/tool routing, worker queues, browser automation, large files | Focused timing, complexity review, query/count check, or explicit cost/latency rationale | Main path, repeated tasks, expensive models, user-visible slowness, scale-sensitive code |
+| Accessibility | UI, keyboard flow, forms, visual states, text contrast, semantic structure | Browser smoke, component inspection, keyboard/focus check, or accessibility tool result when available | User-facing UI, forms, navigation, mobile/responsive layout, public release |
+| Resilience/recovery | Retry, cancellation, timeout, idempotency, duplicate prevention, state recovery, fallback | Failure-path inspection, focused test/smoke for retry/cancel/error state, recovery record when interrupted | Worker/runtime changes, long tasks, external APIs, stateful workflows, release rollback |
+| UI/browser | Visual behavior, loading/empty/error/success states, routing, layout, streaming, browser automation | Browser smoke, screenshot/visual inspection, component test, or DOM/state inspection | Main user flow, responsive UI, visual regression risk, rich interaction |
+| API/state | API contracts, persistence, state machines, cache, sessions, concurrency, idempotency | Focused API smoke, state transition test, schema/config inspection, replay/idempotency check | Public API, cross-session state, migrations, concurrent writes, data retention |
+| Data/migration | Schema, storage, generated artifacts, imports/exports, backward compatibility | Migration/rollback notes, fixture data smoke, backup/restore plan, compatibility check | Production data, irreversible transform, downgrade uncertainty, multi-version support |
+| Model/tool routing | Model provider, tool call, MCP, browser, subagent, permission, cost route | Tool status marked documented/verified/unknown/unavailable; provider/model behavior verified only after execution | New provider, fallback, sensitive data, expensive model, hidden tool traces |
+| Release/operations | Install, update, release notes, rollback, incident, observability | `references/release.md`, `references/recovery.md`, release readiness audit, known risks | Public handoff, package update, runtime compatibility, incident hotfix |
+
+## Evidence Mapping
+
+Use the narrowest evidence that would fail if the changed behavior were broken.
+
+- File inspection can verify docs, templates, source-of-truth boundaries, and secret absence in touched files.
+- Focused tests can verify code behavior, state transitions, error paths, and regressions.
+- API smokes can verify contracts, persistence, and session behavior.
+- Browser smokes can verify UI, accessibility basics, streaming, loading/error states, and layout-sensitive flows.
+- Architecture/review scans can verify coupling, ownership, release risk, and residual risk when runtime execution is not available.
+
+If evidence is unavailable, record `unknown` or `not ready`; do not promote to `verified`.
+
+## Review Routing
+
+- Use `references/review.md` for spec compliance, code quality, architecture drift, security/privacy, regression, and evidence review axes.
+- Use `references/architecture-health.md` when the task touches structural boundaries, source-of-truth drift, dependency/security risk, performance/resilience, migration, or release impact.
+- Use `references/release.md` and `references/recovery.md` when domain risk affects release, rollback, migration, incident response, or future-agent continuation.
+- Use `.gse/project-profile.md` for project-specific commands, owners, threat model, performance budget, browser matrix, release gates, and compliance requirements.
+
+## Output Format
+
+Record domain gates compactly:
+
+```text
+Domain gates selected:
+Why selected:
+Evidence run:
+Evidence status: result | verified | accepted | not ready
+Unverified tools:
+Residual risk:
+Next action:
+```
+
+For skipped gates, say why they are not applicable or what evidence would be needed later.