@t275005746/gse 0.1.0 → 0.1.2

package/references/learning-system.md

@@ -1,35 +1,51 @@
-# Learning System
-
-Learnings keep long projects from repeating mistakes.
-
-## Capture When
-
-- User corrects an assumption.
-- A command, tool, API, or integration fails unexpectedly.
-- A bug root cause was non-obvious.
-- A recurring workflow can be shortened or hardened.
-- A missing quality gate allowed a defect through.
-
-## Do Not Capture
-
-- Raw chain of thought.
-- Temporary attempts.
-- Long command output.
-- One-off details unlikely to help future work.
-
-## Upgrade Rule
-
-Use `references/drift-audit.md` when a repeated lesson suggests stale docs, stale project-profile facts, stale host adapters, stale tool assumptions, or stale evidence state.
-
+# Learning System
+
+Learnings keep long projects from repeating mistakes.
+
+## Capture When
+
+- User corrects an assumption.
+- A command, tool, API, or integration fails unexpectedly.
+- A bug root cause was non-obvious.
+- A recurring workflow can be shortened or hardened.
+- A missing quality gate allowed a defect through.
+
+## Do Not Capture
+
+- Raw chain of thought.
+- Temporary attempts.
+- Long command output.
+- One-off details unlikely to help future work.
+
+## Upgrade Rule
+
+Use `references/drift-audit.md` when a repeated lesson suggests stale docs, stale project-profile facts, stale host adapters, stale tool assumptions, or stale evidence state.
+
 - First occurrence: learning note.
 - Second occurrence: checklist or template update.
-- Third occurrence: project rule or quality gate.
+- Third occurrence: project guard, project rule, or quality gate.
 - Fifth occurrence: script, test, or dedicated skill.
 
-## Suggested Stores
+Use `scripts/audit-learning-promotion.mjs --target <project-root> --json` to classify and count repeated lessons. The audit is read-only by default. Use `/gse learn --promote --execute` only to write `.gse/learning-promotions.md` candidate output; it does not mutate `.gse/project-guards.md`, `.gse/quality-gates.md`, templates, scripts, or skill files without a deliberate follow-up change.
+
+Use `scripts/audit-learning-drift.mjs --root <gse-skill> --target <project-root> --json` after promotion analysis. It checks whether promoted guard or script candidates are covered by project guards, quality gates, `/gse continue`, `/gse close`, or a focused audit script. Uncovered high-severity candidates are surfaced as warnings so the next slice can deliberately promote them.
 
+Promotion categories:
+
+- `shell`: shell syntax, host command behavior, Windows/Unix command differences.
+- `encoding`: UTF-8, mojibake, localized document handling.
+- `evidence`: JSONL, evidence levels, stale records, close gates.
+- `browser`: browser smoke, Playwright, screenshot, component-test downgrade.
+- `git`: sparse checkout, staging, commit boundaries.
+- `host-tool`: subagents, MCP, LSP, native slash commands, host runtime claims.
+- `project-rule`: canonical plans, AGENTS.md, local project conventions.
+- `release`: CI, registry, marketplace, security contact, release evidence.
+
+## Suggested Stores
+
 - `.gse/learnings.md` for portable project lessons.
+- `.gse/project-guards.md` for recurring preflight rules promoted from lessons.
 - `.learnings/` when the project already uses that convention.
 - `AGENTS.md` for durable project rules.
 - ADRs for architectural decisions.
-
+

package/references/maintenance-cadence.md

@@ -0,0 +1,51 @@
+# GSE Maintenance Cadence
+
+GSE final form requires recurring checks, not only one-time release proof. This cadence keeps benchmark coverage, drift detection, security review, forward testing, and target-project drills visible while host-native slash-command evidence remains an external gate.
+
+## Cadence Table
+
+| Area | Trigger | Minimum Cadence | Evidence | Command |
+|---|---|---|---|---|
+| Benchmark audit | Non-trivial GSE capability change or new comparable engineering skill | Monthly or before release | `.gse/benchmark-audits/` entry or roadmap update | `node scripts/audit-final-form-roadmap.mjs --root . --json` |
+| Drift audit | Project guard, learning, adapter, command, or state model changes | Weekly or before close | Learning drift and state freshness output | `node scripts/audit-learning-drift.mjs --root . --target . --json` |
+| Dependency and security review | Release, install, package, registry, CI, or external input changes | Monthly or before release | Release trust, CI readiness, and public acceptance outputs | `node scripts/audit-release-trust.mjs --root . --json` |
+| Forward test | Non-trivial routing, command, scaffold, validation, or package change | Before release and after major workflow changes | Fixture or fresh-session forward-test evidence | `node scripts/forward-test-gse.mjs --root . --json` |
+| Target-project hardening drill | GSE adoption, continue, close, host capability, or learning behavior changes | Weekly or before public release | Read-only target drill output | `node scripts/audit-target-hardening-drills.mjs --root . --json` |
+| Public acceptance doctor | Public release, registry, marketplace, host, or owner evidence changes | Before release or public claim | Pending owner/external gate report | `node scripts/audit-public-acceptance-readiness.mjs --root . --json` |
+| Command runner smoke | `/gse` command routing, portable command wrapper, or short-entry behavior changes | Every command-router change | Portable runner output from `scripts/run-gse-command.mjs` | `node scripts/run-gse-command.mjs --root . --target . --command "/gse maintenance" --json --compact` |
+| Installed skill sync | Any capability upgrade shipped from source to installed skill | Every capability upgrade | Installed-copy hash comparison and command smoke from `scripts/audit-installed-sync.mjs` | `node scripts/audit-installed-sync.mjs --root . --installed-root <installed-skill-dir> --json` |
+| Active session sync | Any capability upgrade that should reach active GSE-using sessions | Every capability upgrade when active sessions exist | Honest sent, archived, unavailable, failed, or skipped records from `scripts/record-session-sync.mjs` plus `scripts/audit-session-sync.mjs` | `node scripts/audit-session-sync.mjs --root . --require-installed --require-thread <thread-id> --json` |
+
+## Maintenance Snapshot
+
+Use a snapshot when the goal is to prove that the recurring checks actually ran, not only that the cadence is documented.
+
+```powershell
+node scripts/generate-maintenance-snapshot.mjs --root . --target . --installed-root <installed-skill-dir> --execute --json
+```
+
+The canonical output is `.gse/maintenance/latest-maintenance-snapshot.json` plus a Markdown sibling. Without `--installed-root`, the installed-sync row is package-only and must not be used as installed-copy freshness proof.
+
+For an installed package smoke, use package mode so source-worktree-only roadmap and release-bundle freshness checks do not become false blockers:
+
+```powershell
+node scripts/generate-maintenance-snapshot.mjs --root <installed-skill-dir> --target <installed-skill-dir> --package-smoke --skip-release-bundle --json
+```
+
+Package smoke proves the installed copy can run the maintenance command set. The source repository remains responsible for canonical roadmap, release bundle, and installed-root freshness evidence.
+
+## Close Rule
+
+Maintenance evidence is not a substitute for native host evidence, public CI, marketplace approval, or owner acceptance. It only proves that GSE has a repeatable upkeep loop and that remaining external gates stay visible.
+
+Before claiming a maintenance-sensitive slice complete, run:
+
+```powershell
+node scripts/audit-maintenance-cadence.mjs --root . --json
+node scripts/generate-maintenance-snapshot.mjs --root . --target . --installed-root <installed-skill-dir> --execute --json
+node scripts/audit-maintenance-snapshot.mjs --root . --json
+node scripts/run-gse-command.mjs --root . --target . --command "/gse maintenance" --json --compact
+node scripts/audit-installed-sync.mjs --root . --installed-root <installed-skill-dir> --json
+node scripts/audit-session-sync.mjs --root . --json
+node scripts/run-validation-profile.mjs --target . --profile lite --json
+```

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.