@t275005746/gse 0.1.0 → 0.1.2

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/commands.md

@@ -19,9 +19,10 @@ node <gse-skill>/scripts/run-gse-command.mjs --target <gse-skill> --command "/gs
 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
-```
+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
+node <gse-skill>/scripts/run-gse-command.mjs --target <project-root> --command "/gse repair" --json
+```
 
 Validation profile helper:
 
@@ -44,22 +45,24 @@ The Claude adapter writes `.claude/commands/gse.md`, matching Claude Code's docu
 | `/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 continue` | Continue the current project through a hard preflight and compact state packet | Execute workflow | project rules, `.gse/state.json`, evidence index, `.gse/project-profile.md`, quality gates, goal map or canonical plan | continue preflight plus focused test/smoke for the slice |
+| `/gse status` | Show current project state; for the GSE skill, show final-form progress and pending public/host claim evidence | Status workflow | `.gse/state.json`; for GSE skill, final readiness audits | state/report inspection |
+| `/gse doctor` | Diagnose public/host claim evidence 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 repair` | Diagnose or repair stale state, broken evidence JSONL, and overlong residual risks | State/evidence repair workflow | `.gse/state.json`, `.gse/evidence/index.jsonl`, latest evidence files | state repair audit; optional execute-gated residual risk compaction |
+| `/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 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 maintenance` | Audit recurring maintenance coverage for benchmark, drift, security, forward-test, target drills, public acceptance, and installed sync | Maintenance workflow | `maintenance-cadence.md`, validation profile, current final-form state | maintenance cadence 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 learn` | Record a reusable lesson in `.gse/learnings.md`; with `--promote`, classify repeated lessons into promotion candidates | Learning workflow | summary, trigger, source, optional impact, optional `--promote` | learning command and promotion audits |
 | `/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 |
+| `/gse close` | Check whether the current slice is ready to close | Close readiness check | `.gse/state.json`, evidence index, quality gates, role fallback packets, git status | close gate audit |
 
 ## Aliases
 
@@ -68,17 +71,19 @@ The Claude adapter writes `.claude/commands/gse.md`, matching Claude Code's docu
 - `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 status` -> `/gse status`
+- `gse doctor` -> `/gse doctor`
+- `gse repair` -> `/gse repair`
+- `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 install` -> `/gse install`
+- `gse public-release` -> `/gse public-release`
+- `gse maintenance` -> `/gse maintenance`
+- `gse change` -> `/gse change`
 - `gse spec` -> `/gse change`
 - `gse slice` -> `/gse slice`
 - `gse verify` -> `/gse verify`
@@ -92,19 +97,28 @@ The Claude adapter writes `.claude/commands/gse.md`, matching Claude Code's docu
 /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>
-```
+Expected behavior:
+
+1. Enter the project root.
+2. Run the hard preflight: `.gse/state.json`, `.gse/evidence/index.jsonl`, `.gse/project-profile.md`, `.gse/goal-map.md`, `.gse/quality-gates.md`, canonical plan, current slice, residual risks, and owner/external gates when the target exposes them.
+3. Return a compact state packet with project identity, phase, current slice, next action, top risks, blocked gates, gate taxonomy, tool statuses, latest evidence, active project guards, next checks, and `completionPlan`.
+4. Fail before implementation when local state or evidence index is broken.
+5. Keep owner/external evidence visible as public/release/host-specific claim requirements without converting it into GSE core workflow debt.
+6. Use `completionPlan.requiredSteps`, `completionPlan.requiredCloseCommands`, and active `completionPlan.conditionalCloseCommands` as the exact close checklist before claiming a slice is done.
+7. Use `gateTaxonomy` to distinguish default core blockers from release gates and host-adapter claim gates. Release and host-adapter gates block only the specific claim unless project policy promotes them.
+8. 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-continue-packet.mjs --target <project-root>
+```
+
+Project guard helper:
+
+```text
+node <gse-skill>/scripts/audit-project-guards.mjs --target <project-root> --json
+```
 
 For existing projects that have `.gse/` but do not yet have machine-readable continuation files:
 
@@ -163,7 +177,8 @@ Expected behavior:
 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"
+/gse learn --summary "Prefer UTF-8 safe readers for Chinese docs before judging mojibake" --trigger "encoding review" --source "project slice"
+/gse learn --promote
 ```
 
 Expected behavior:
@@ -172,7 +187,8 @@ Expected behavior:
 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.
+5. Keep raw chain-of-thought, long logs, and temporary attempts out of learnings.
+6. With `--promote`, run learning promotion analysis. Add `--execute` only to write candidate-only `.gse/learning-promotions.md`; do not mutate guards, gates, templates, scripts, or skill files automatically.
 
 ```text
 /gse status
@@ -181,22 +197,34 @@ Expected behavior:
 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`.
+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 release evidence, and `publicAccepted`.
 3. Do not treat status output as completion evidence unless the relevant gate audit is also recorded.
 
-```text
-/gse doctor
-```
+```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.
+1. For the GSE skill package, run the public acceptance doctor and list pending owner/external claim evidence 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
-```
+3. Keep owner-required and external-required gates explicit. Do not convert local mechanics into public acceptance.
+
+```text
+/gse repair
+```
+
+Expected behavior:
+
+1. Read `.gse/state.json` and `.gse/evidence/index.jsonl`.
+2. Return concrete repair actions for invalid state JSON, invalid evidence JSONL, missing latest evidence files, stale state/evidence next actions, and overlong residual risks.
+3. Stay read-only by default.
+4. Automatic writes are limited to reversible residual-risk compaction with a backup, and require `--execute`.
+5. Do not guess or overwrite broken JSON/JSONL; report the file and line/error so the owner or agent can repair deliberately.
+
+```text
+/gse owner-actions
+```
 
 Expected behavior:
 
@@ -278,7 +306,7 @@ Expected behavior:
 ## 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.
+- `/gse close` is read-only in the portable command runner. It checks state, evidence, role dispatch honesty, worktree ownership, staged generated artifacts, and `.gse` git state. It cannot mark a slice complete, archive a change, or write evidence by itself.
 - Portable close check:
 
 ```text
@@ -291,5 +319,6 @@ node <gse-skill>/scripts/audit-close-gate.mjs --target <project-root>
 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 maintenance` verifies recurring upkeep coverage and command wiring; it does not replace real external host, CI, marketplace, or owner evidence.
+- `/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

@@ -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.