@t275005746/gse 0.1.0 → 0.1.1

package/references/marketplace-discovery.md

@@ -1,46 +1,46 @@
-# Marketplace Discovery
-
-Use this when preparing GSE for a public catalog, skill marketplace, plugin listing, GitHub release page, or internal agent-workflow registry.
-
-Discovery metadata should help people find and evaluate GSE without overstating trust.
-
-## Required Metadata
-
-- Name and display name.
-- Short tagline and summary.
-- Categories and keywords that describe the workflow naturally.
-- Entrypoints for humans and agents.
-- Validation commands.
-- Distribution and signing references.
-- Host support status with honest labels.
-- Boundaries and unverified claims.
-
-The canonical local metadata file is:
-
-```text
-assets/marketplace/gse-listing.json
-```
-
-## Search Language
-
-Use normal explanatory language around terms such as agentic engineering, spec-driven development, SDD, AI coding agents, goal maps, evidence gates, OpenSpec-style changes, and Superpowers-style execution. Do not add isolated search-term blocks that read like keyword stuffing.
-
-## Trust Boundary
-
-Discovery metadata is not marketplace approval.
-
-A listing can be:
-
-- `result`: drafted metadata exists.
-- `verified`: metadata passes local audit and matches package validation.
-- `accepted`: the target marketplace, catalog owner, or release owner accepts it.
-
-## Validation
-
-Run:
-
-```text
-node <skill>/scripts/audit-marketplace-discovery.mjs --root <skill> --json
-```
-
-For release trust, also use `references/release-trust.md`.
+# Marketplace Discovery
+
+Use this when preparing GSE for a public catalog, skill marketplace, plugin listing, GitHub release page, or internal agent-workflow registry.
+
+Discovery metadata should help people find and evaluate GSE without overstating trust.
+
+## Required Metadata
+
+- Name and display name.
+- Short tagline and summary.
+- Categories and keywords that describe the workflow naturally.
+- Entrypoints for humans and agents.
+- Validation commands.
+- Distribution and signing references.
+- Host support status with honest labels.
+- Boundaries and unverified claims.
+
+The canonical local metadata file is:
+
+```text
+assets/marketplace/gse-listing.json
+```
+
+## Search Language
+
+Use normal explanatory language around terms such as agentic engineering, spec-driven development, SDD, AI coding agents, goal maps, evidence gates, OpenSpec-style changes, and Superpowers-style execution. Do not add isolated search-term blocks that read like keyword stuffing.
+
+## Trust Boundary
+
+Discovery metadata is not marketplace approval.
+
+A listing can be:
+
+- `result`: drafted metadata exists.
+- `verified`: metadata passes local audit and matches package validation.
+- `accepted`: the target marketplace, catalog owner, or release owner accepts it.
+
+## Validation
+
+Run:
+
+```text
+node <skill>/scripts/audit-marketplace-discovery.mjs --root <skill> --json
+```
+
+For release trust, also use `references/release-trust.md`.

package/references/model-routing.md

@@ -1,103 +1,103 @@
-# Model Routing
-
-Use this when GSE work needs to choose a model, provider, hosted tool, local tool, browser agent, worker, or role-specific agent capability.
-
-## Core Rule
-
-Route by capability first, then cost, latency, privacy, context size, tool use, reliability, and evidence.
-
-Do not hard-code one provider, one model family, or one host as the GSE default. Projects may define preferred providers, but GSE must preserve a portable fallback path.
-
-## Capability-First Selection
-
-Define the task capability before picking a model:
-
-| Capability | Typical use | Routing preference |
-|---|---|---|
-| Fast classification | triage, route selection, small labels | lowest reliable latency/cost |
-| Code location | symbol search, call chains, existing tests | LSP/index/search before stronger model reasoning |
-| Mechanical edit | narrow transforms, boilerplate, local fixes | lower-cost coding-capable model if verification is strong |
-| Implementation | bounded code slice, tests, integration | standard coding model with project context |
-| Architecture/root cause | invariants, multi-file reasoning, debugging | highest-reasoning model available and approved |
-| Review/QA | spec compliance, security, regressions, UI evidence | independent reviewer model or fresh context when risk is high |
-| Long context synthesis | session working set, docs, logs, migration notes | model with adequate context and summarization behavior |
-| Tool/worker execution | browser, shell, MCP, CI, queue, runtime worker | verified host/tool adapter, not just model choice |
-
-## Status Vocabulary
-
-Keep model availability separate from model behavior.
-
-- `documented`: project docs, provider config, or host settings mention the model/tool.
-- `verified`: this session or project evidence ran the model/tool successfully for the relevant capability.
-- `unknown`: no trustworthy evidence yet.
-- `unavailable`: expected model/tool is missing, blocked, failing, or forbidden.
-
-A documented model is not verified. A verified chat response does not verify tool use, long context, latency, cost, or privacy behavior.
-
-## Routing Inputs
-
-Record these in `.gse/project-profile.md`, `.gse/tooling.md`, or a host adapter when relevant:
-
-- Provider or host:
-- Model/tool id:
-- Capability:
-- Status: documented | verified | unknown | unavailable
-- Evidence path or command:
-- Cost tier:
-- Latency expectation:
-- Context limit or practical context budget:
-- Tool-use support:
-- Privacy/security boundary:
-- Fallback:
-- Known failure modes:
-
-## Decision Order
-
-1. Use project-specific routing rules if they exist and do not conflict with current user instruction.
-2. Prefer verified local tools for code location, tests, browser smoke, and CI before spending model reasoning.
-3. Choose the cheapest/fastest model that can satisfy the capability with adequate verification.
-4. Escalate to a stronger model when there is a clear reasoning, context, safety, or integration gap.
-5. Use fresh context for review, QA, or high-risk architecture when current-session context may bias the result.
-6. Fall back to a documented or generic model only when the task risk is low or verification can catch mistakes.
-7. Record residual risk when model behavior is unknown or only structurally verified.
-
-## Fallback Rules
-
-- If preferred model is unavailable, use the next project-approved model with the same capability class.
-- If tool-use support is unavailable, switch to manual shell/browser/CI verification when possible.
-- If long-context support is unavailable, build a smaller working set and record omitted context.
-- If privacy constraints forbid remote models, use local tools, local models, or ask for a project-approved path.
-- If cost is high, reduce context, split the task, or use lower-tier models for locator/QA roles.
-- Do not claim a fallback preserved quality unless focused evidence proves it.
-
-## Evidence Requirements
-
-For model routing claims, record:
-
-```text
-Capability:
-Chosen model/tool:
-Why this route:
-Status: documented | verified | unknown | unavailable
-Cost/latency notes:
-Context/tool-use notes:
-Privacy/security notes:
-Fallback:
-Evidence:
-Residual risk:
-```
-
-## What Not To Do
-
-- Do not route all tasks to the strongest model by default.
-- Do not route all tasks to the cheapest model when failure would be expensive.
-- Do not treat provider marketing claims as project evidence.
-- Do not expose secrets, raw provider payloads, hidden reasoning, or private tool traces in user-facing output.
-- Do not confuse model routing with provider adapter implementation.
-
-## Project Integration
-
-- `references/project-profile.md` records project-approved providers, model/tool ids, privacy limits, and fallback policy.
-- `references/tool-adapters.md` records availability and verification status for host tools and model-backed tools.
-- `references/host-adapters.md` records host-specific model, subagent, MCP, browser, and worker capabilities.
-- `references/evidence-taxonomy.md` decides whether routing evidence is result, verified, or accepted.
+# Model Routing
+
+Use this when GSE work needs to choose a model, provider, hosted tool, local tool, browser agent, worker, or role-specific agent capability.
+
+## Core Rule
+
+Route by capability first, then cost, latency, privacy, context size, tool use, reliability, and evidence.
+
+Do not hard-code one provider, one model family, or one host as the GSE default. Projects may define preferred providers, but GSE must preserve a portable fallback path.
+
+## Capability-First Selection
+
+Define the task capability before picking a model:
+
+| Capability | Typical use | Routing preference |
+|---|---|---|
+| Fast classification | triage, route selection, small labels | lowest reliable latency/cost |
+| Code location | symbol search, call chains, existing tests | LSP/index/search before stronger model reasoning |
+| Mechanical edit | narrow transforms, boilerplate, local fixes | lower-cost coding-capable model if verification is strong |
+| Implementation | bounded code slice, tests, integration | standard coding model with project context |
+| Architecture/root cause | invariants, multi-file reasoning, debugging | highest-reasoning model available and approved |
+| Review/QA | spec compliance, security, regressions, UI evidence | independent reviewer model or fresh context when risk is high |
+| Long context synthesis | session working set, docs, logs, migration notes | model with adequate context and summarization behavior |
+| Tool/worker execution | browser, shell, MCP, CI, queue, runtime worker | verified host/tool adapter, not just model choice |
+
+## Status Vocabulary
+
+Keep model availability separate from model behavior.
+
+- `documented`: project docs, provider config, or host settings mention the model/tool.
+- `verified`: this session or project evidence ran the model/tool successfully for the relevant capability.
+- `unknown`: no trustworthy evidence yet.
+- `unavailable`: expected model/tool is missing, blocked, failing, or forbidden.
+
+A documented model is not verified. A verified chat response does not verify tool use, long context, latency, cost, or privacy behavior.
+
+## Routing Inputs
+
+Record these in `.gse/project-profile.md`, `.gse/tooling.md`, or a host adapter when relevant:
+
+- Provider or host:
+- Model/tool id:
+- Capability:
+- Status: documented | verified | unknown | unavailable
+- Evidence path or command:
+- Cost tier:
+- Latency expectation:
+- Context limit or practical context budget:
+- Tool-use support:
+- Privacy/security boundary:
+- Fallback:
+- Known failure modes:
+
+## Decision Order
+
+1. Use project-specific routing rules if they exist and do not conflict with current user instruction.
+2. Prefer verified local tools for code location, tests, browser smoke, and CI before spending model reasoning.
+3. Choose the cheapest/fastest model that can satisfy the capability with adequate verification.
+4. Escalate to a stronger model when there is a clear reasoning, context, safety, or integration gap.
+5. Use fresh context for review, QA, or high-risk architecture when current-session context may bias the result.
+6. Fall back to a documented or generic model only when the task risk is low or verification can catch mistakes.
+7. Record residual risk when model behavior is unknown or only structurally verified.
+
+## Fallback Rules
+
+- If preferred model is unavailable, use the next project-approved model with the same capability class.
+- If tool-use support is unavailable, switch to manual shell/browser/CI verification when possible.
+- If long-context support is unavailable, build a smaller working set and record omitted context.
+- If privacy constraints forbid remote models, use local tools, local models, or ask for a project-approved path.
+- If cost is high, reduce context, split the task, or use lower-tier models for locator/QA roles.
+- Do not claim a fallback preserved quality unless focused evidence proves it.
+
+## Evidence Requirements
+
+For model routing claims, record:
+
+```text
+Capability:
+Chosen model/tool:
+Why this route:
+Status: documented | verified | unknown | unavailable
+Cost/latency notes:
+Context/tool-use notes:
+Privacy/security notes:
+Fallback:
+Evidence:
+Residual risk:
+```
+
+## What Not To Do
+
+- Do not route all tasks to the strongest model by default.
+- Do not route all tasks to the cheapest model when failure would be expensive.
+- Do not treat provider marketing claims as project evidence.
+- Do not expose secrets, raw provider payloads, hidden reasoning, or private tool traces in user-facing output.
+- Do not confuse model routing with provider adapter implementation.
+
+## Project Integration
+
+- `references/project-profile.md` records project-approved providers, model/tool ids, privacy limits, and fallback policy.
+- `references/tool-adapters.md` records availability and verification status for host tools and model-backed tools.
+- `references/host-adapters.md` records host-specific model, subagent, MCP, browser, and worker capabilities.
+- `references/evidence-taxonomy.md` decides whether routing evidence is result, verified, or accepted.

package/references/open-source-defaults.md

@@ -1,39 +1,39 @@
-# GSE Open-Source Defaults
-
-Use this reference when preparing GSE for a public repository or when a project asks to follow the mainstream open-source path.
-
-## Recommended Default
-
-GSE's owner-approved default route is:
-
-- License: MIT.
-- Repository: public GitHub repository.
-- CI: GitHub Actions with required checks.
-- Security: `SECURITY.md` plus GitHub Security Advisory or another owner-approved public disclosure path.
-- Release channel: GitHub Release first; package registry or marketplace only after real publication evidence exists.
-- Command UX: portable `/gse ...` commands, with native slash-command claims only after a host runtime record proves native execution.
-
-## Why This Default
-
-- MIT is widely understood by open-source tool users and keeps integration friction low.
-- GitHub public repository plus GitHub Actions gives public, linkable evidence for repository settings and CI.
-- GitHub Release provides a simple first public channel without pretending a registry or marketplace approved the package.
-- Portable `/gse ...` command semantics work across hosts even when native slash-command APIs differ.
-
-## Claim Boundaries
-
-- A local `LICENSE` file proves the license text exists; accepted license status requires an owner-approved release record.
-- A local GitHub Actions workflow file does not prove public CI. Use a real public run URL and `scripts/record-public-ci-run.mjs`.
-- A local `SECURITY.md` does not prove a public security contact. Use `scripts/record-public-security-contact.mjs` after the disclosure path is public and owner-approved.
-- A generated package or release bundle does not prove public publication. Use `scripts/record-public-channel-publication.mjs` after a real channel URL exists.
-- Generated host adapter pointers do not prove native slash commands. Use `scripts/record-host-invocation.mjs` with real host evidence.
-
-## Minimal Public Release Order
-
-1. Record the owner-approved MIT license decision.
-2. Publish or mirror GSE into a public GitHub repository.
-3. Enable repository settings: issues, pull requests, security policy visibility, branch protection, required checks, review before merge, conversation resolution, force-push restriction, and deletion restriction.
-4. Run public GitHub Actions and record the run URL, commit SHA, branch, and required checks.
-5. Create a GitHub Release and record the release URL.
-6. Record host runtime invocation evidence for each claimed host.
-7. Re-run final readiness and public acceptance audits.
+# GSE Open-Source Defaults
+
+Use this reference when preparing GSE for a public repository or when a project asks to follow the mainstream open-source path.
+
+## Recommended Default
+
+GSE's owner-approved default route is:
+
+- License: MIT.
+- Repository: public GitHub repository.
+- CI: GitHub Actions with required checks.
+- Security: `SECURITY.md` plus GitHub Security Advisory or another owner-approved public disclosure path.
+- Release channel: GitHub Release first; package registry or marketplace only after real publication evidence exists.
+- Command UX: portable `/gse ...` commands, with native slash-command claims only after a host runtime record proves native execution.
+
+## Why This Default
+
+- MIT is widely understood by open-source tool users and keeps integration friction low.
+- GitHub public repository plus GitHub Actions gives public, linkable evidence for repository settings and CI.
+- GitHub Release provides a simple first public channel without pretending a registry or marketplace approved the package.
+- Portable `/gse ...` command semantics work across hosts even when native slash-command APIs differ.
+
+## Claim Boundaries
+
+- A local `LICENSE` file proves the license text exists; accepted license status requires an owner-approved release record.
+- A local GitHub Actions workflow file does not prove public CI. Use a real public run URL and `scripts/record-public-ci-run.mjs`.
+- A local `SECURITY.md` does not prove a public security contact. Use `scripts/record-public-security-contact.mjs` after the disclosure path is public and owner-approved.
+- A generated package or release bundle does not prove public publication. Use `scripts/record-public-channel-publication.mjs` after a real channel URL exists.
+- Generated host adapter pointers do not prove native slash commands. Use `scripts/record-host-invocation.mjs` with real host evidence.
+
+## Minimal Public Release Order
+
+1. Record the owner-approved MIT license decision.
+2. Publish or mirror GSE into a public GitHub repository.
+3. Enable repository settings: issues, pull requests, security policy visibility, branch protection, required checks, review before merge, conversation resolution, force-push restriction, and deletion restriction.
+4. Run public GitHub Actions and record the run URL, commit SHA, branch, and required checks.
+5. Create a GitHub Release and record the release URL.
+6. Record host runtime invocation evidence for each claimed host.
+7. Re-run final readiness and public acceptance audits.

package/references/operating-model.md

@@ -1,52 +1,52 @@
-# Operating Model
-
-Use the same loop for every task, scaled by task level.
-
-## 1. Goal
-
-Identify the project goal, user outcome, current priority, and non-goals.
-
-For long-running work, bind to `.gse/goal-map.md` or the project's existing goal map.
-
-## 2. Spec
-
-Define boundaries before implementation:
-
-- Inputs and outputs
-- UI/API/state behavior
-- Error and recovery behavior
-- Permissions and privacy boundaries
-- Acceptance criteria
-- Test or smoke plan
-
-Do not over-spec Level 1 tasks.
-
-## 3. Execute
-
-Use the smallest verifiable slice.
-
-- Locate code with `rg`, `rg --files`, LSP, or an index before editing.
-- Follow existing patterns.
-- Keep unrelated refactors out.
-- Use subagents only when actual dispatch tools exist and ownership is clear.
-- Use `references/file-ownership.md` before editing dirty files, shared files, or files assigned to another role.
-- Avoid making every internal state transition its own product slice. When several small states only matter as one user-visible chain, merge them and verify the chain.
-
-## 4. Evidence
-
-Completion needs evidence appropriate to the risk:
-
-- Unit/component/contract test
-- API smoke
-- Browser or Playwright smoke
-- Build/typecheck/lint
-- Screenshot or trace for UI
-- Commit hash or change summary
-
-Choose the gate profile from `references/task-levels.md` and `references/quality-gates.md`. A small docs or state slice should not pay the same verification cost as a release/install/cross-host slice. Conversely, release, public contract, install, and host-runtime claims need hard gates and cannot be proven by narrow tests alone.
-
-## 5. Learn
-
-Record reusable lessons when a failure, correction, tool gap, repeated bug, or better process is discovered.
-
-Escalate repeated lessons into quality gates or project rules.
+# Operating Model
+
+Use the same loop for every task, scaled by task level.
+
+## 1. Goal
+
+Identify the project goal, user outcome, current priority, and non-goals.
+
+For long-running work, bind to `.gse/goal-map.md` or the project's existing goal map.
+
+## 2. Spec
+
+Define boundaries before implementation:
+
+- Inputs and outputs
+- UI/API/state behavior
+- Error and recovery behavior
+- Permissions and privacy boundaries
+- Acceptance criteria
+- Test or smoke plan
+
+Do not over-spec Level 1 tasks.
+
+## 3. Execute
+
+Use the smallest verifiable slice.
+
+- Locate code with `rg`, `rg --files`, LSP, or an index before editing.
+- Follow existing patterns.
+- Keep unrelated refactors out.
+- Use subagents only when actual dispatch tools exist and ownership is clear.
+- Use `references/file-ownership.md` before editing dirty files, shared files, or files assigned to another role.
+- Avoid making every internal state transition its own product slice. When several small states only matter as one user-visible chain, merge them and verify the chain.
+
+## 4. Evidence
+
+Completion needs evidence appropriate to the risk:
+
+- Unit/component/contract test
+- API smoke
+- Browser or Playwright smoke
+- Build/typecheck/lint
+- Screenshot or trace for UI
+- Commit hash or change summary
+
+Choose the gate profile from `references/task-levels.md` and `references/quality-gates.md`. A small docs or state slice should not pay the same verification cost as a release/install/cross-host slice. Conversely, release, public contract, install, and host-runtime claims need hard gates and cannot be proven by narrow tests alone.
+
+## 5. Learn
+
+Record reusable lessons when a failure, correction, tool gap, repeated bug, or better process is discovered.
+
+Escalate repeated lessons into quality gates or project rules.