@t275005746/gse 0.1.0

package/references/drift-audit.md

@@ -0,0 +1,81 @@
+# Drift Audit
+
+Use this when project reality may have diverged from `.gse/`, project docs, generated scaffolds, host adapters, tool assumptions, model routing, or recorded evidence.
+
+Drift audit keeps long-running agent work from following stale instructions. It is a focused consistency check, not a broad rewrite.
+
+## Trigger Conditions
+
+Run a drift audit when any of these are true:
+
+- A command fails because package manager, runtime, service port, CI, browser, MCP, LSP, model, or host capability assumptions were stale.
+- The user says a tool, standard, permission, or host capability exists but GSE cannot see it.
+- `.gse/project-profile.md`, `.gse/tooling.md`, `.gse/goal-map.md`, `.gse/quality-gates.md`, or evidence records disagree with current project files.
+- Generated scaffolds or host adapters were copied earlier and may no longer point to `.gse/` as the source of truth.
+- A model/provider/tool route was previously documented but not recently verified.
+- Release, recovery, incident, or repeated failure evidence suggests stale rules or stale assumptions.
+- A future agent would likely choose the wrong workflow because old docs are more visible than current facts.
+
+Do not run a broad drift audit for a tiny local edit unless the edit exposes stale project facts.
+
+## Drift Categories
+
+| Category | Examples | Default remediation |
+|---|---|---|
+| stale docs | README, AGENTS.md, architecture docs, ADRs, comments, old handoffs | Update or mark outdated; link to current source of truth |
+| stale generated scaffolds | `.gse/` templates, copied host folders, generated commands, stale examples | Regenerate or patch the smallest affected artifact |
+| stale host adapters | `.codex/`, `.claude/`, `.agents/`, MCP, hooks, subagent notes, runtime bridges | Point back to `.gse/`; update verified/unknown capability status |
+| stale tool assumptions | package manager, scripts, ports, CI, browser, LSP, MCP, deployment, observability | Re-read project config; mark verified, documented, unknown, or unavailable |
+| stale model assumptions | provider/model ids, capability fit, cost, latency, privacy, fallback, hosted tools | Reclassify with model-routing evidence; avoid claiming support without proof |
+| stale project profile facts | identity, commands, standards, release rules, permissions, known gotchas | Refresh `.gse/project-profile.md` from current files only |
+| stale evidence or goal-map state | completed work not reflected, obsolete next action, old risk still listed, missing residual risk | Update `.gse/evidence/`, `.gse/goal-map.md`, or `.gse/current-slice.md` concisely |
+
+## Minimum Audit Record
+
+Use this format in evidence logs or handoff notes:
+
+```text
+Drift scope:
+Drift category:
+Current source checked:
+Stale or conflicting record:
+Finding:
+Remediation:
+Evidence:
+Follow-up slices:
+```
+
+Findings must come from current files, command output, local tool help, trusted project docs, or focused experiments. If the evidence is indirect, record a risk instead of a finding.
+
+## Evidence Requirements
+
+A drift audit should prove at least one of these:
+
+- The recorded assumption still matches current project reality.
+- The recorded assumption is stale and has been corrected or marked outdated.
+- The current evidence is insufficient, so the status is `unknown` or a follow-up slice is required.
+- The project has conflicting sources of truth and an owner decision is needed.
+
+Use `verified`, `documented`, `unknown`, and `unavailable` consistently with references/tool-adapters.md. Do not promote `documented` or `unknown` to `verified` without current evidence.
+
+## Remediation Paths
+
+Choose the smallest durable remediation:
+
+- Refresh `.gse/project-profile.md` when project commands, tools, standards, permissions, release rules, or known gotchas changed.
+- Refresh `.gse/goal-map.md` or `.gse/current-slice.md` when next action, risks, or landed evidence are stale.
+- Refresh host adapter notes when host-specific folders duplicate policy or claim unavailable capabilities.
+- Refresh tool/model routing notes when provider, model, MCP, LSP, browser, CI, or deployment assumptions changed.
+- Add a learning entry only when the drift pattern is reusable beyond the current slice.
+- Add or update a script/template/gate when the same drift appears repeatedly.
+
+Never update stale docs by inventing support. Prefer `unknown` plus a focused verification action.
+
+## Integration
+
+- Use references/project-profile.md when drift affects project-specific standards, commands, tools, permissions, release rules, or known gotchas.
+- Use references/host-adapters.md when drift affects Codex, Claude Code, Hermes/AION-style runtime, WorkBuddy, MCP, hooks, skills, subagents, or host-specific folders.
+- Use references/tool-adapters.md when drift affects tool status, LSP/index, browser, CI, MCP, package manager, or command assumptions.
+- Use references/model-routing.md when drift affects provider/model capability, cost, latency, privacy, fallback, or hosted tool behavior.
+- Use references/learning-system.md when a drift pattern should be promoted into a lesson, checklist, gate, script, or skill update.
+- Use references/recovery.md when drift is discovered during interrupted, failed, or handed-off work.

package/references/evidence-taxonomy.md

@@ -0,0 +1,123 @@
+# Evidence Taxonomy
+
+Use this to decide whether work is only produced, actually verified, or accepted.
+
+GSE uses three evidence gates:
+
+```text
+result -> verified -> accepted
+```
+
+Do not skip gates. Do not claim a higher gate when the evidence only proves a lower gate.
+
+## Gate 1: Result
+
+`result` means the requested artifact or change exists.
+
+Enough evidence:
+
+- File, script, template, reference, commit, report, screenshot, or generated output exists.
+- The change is scoped to the requested slice.
+- The agent can point to the exact path or output.
+
+Not enough for `result`:
+
+- A plan to create the artifact.
+- A final answer describing what would be changed.
+- A command that was intended to write a file but did not confirm the file exists.
+
+Example:
+
+- `scripts/audit-gse.mjs` exists: result.
+- `.gse/project-profile.md` was written in a temp fixture: result.
+
+## Gate 2: Verified
+
+`verified` means the result was checked against acceptance criteria with evidence appropriate to the risk.
+
+Enough evidence:
+
+- Focused test, smoke, structure check, build, typecheck, lint, browser check, API check, or manual inspection directly covers the acceptance criteria.
+- The command output or inspected artifact proves the expected behavior.
+- Known residual risk is recorded.
+
+Not enough for `verified`:
+
+- The file exists but was not inspected.
+- A broad test passed but does not cover the changed behavior.
+- A command ran without checking the relevant output.
+- A tool is merely configured or documented but not run.
+- The agent says it looks right without evidence.
+
+Example:
+
+- `audit-gse.mjs` reports `GSE-C04` as `strong (2/2, score 1)` after adding `router.md`: verified for the router structural criterion.
+- A project profile lists Playwright as `documented` because config exists: not verified tool availability.
+
+## Gate 3: Accepted
+
+`accepted` means the verified result has been accepted by the required authority.
+
+Enough evidence:
+
+- The user explicitly accepts the result.
+- A required reviewer or gate approves it.
+- A release, archive, or project process marks it accepted.
+- A pre-defined acceptance policy says verified evidence is sufficient for this task level.
+
+Not enough for `accepted`:
+
+- The agent is satisfied.
+- The result passed a local smoke but no acceptance policy says that is enough.
+- The user has not reviewed a user-facing, policy, release, or irreversible change when review is required.
+
+Example:
+
+- A focused smoke passes for an internal script: can be accepted by policy if the task is Lite or Standard and no human approval is required.
+- A release plan or public workflow change usually needs explicit human acceptance or release-gate acceptance.
+
+## Required Evidence Record
+
+Every non-trivial GSE slice should record:
+
+```text
+Outcome:
+Scope:
+Acceptance:
+Result evidence:
+Verification evidence:
+Accepted by:
+Residual risk:
+Next action:
+```
+
+Use `accepted by: policy` only when the applicable policy is named, such as `Lite focused smoke policy`.
+
+For project-local GSE updates, scaffold changes, host adapter changes, and release-readiness work, use `assets/templates/update-release-acceptance-record.md` so local decisions preserved, changed files, rollback notes, owner gate, accepted-by status, residual risks, and next action are not lost.
+
+## Status Rules
+
+- `planned`: desired but no result yet.
+- `result`: artifact/change exists but has not been verified.
+- `verified`: acceptance criteria are directly covered by evidence.
+- `accepted`: verified result has user, reviewer, release, archive, or policy acceptance.
+- `blocked`: meaningful progress cannot continue and the blocker satisfies the project's blocked rule.
+
+## Tool Status Is Separate
+
+Do not confuse evidence gates with tool availability status.
+
+- `documented`: a file says a tool or command exists.
+- `verified`: the tool or command was actually run or checked.
+- `unknown`: no trustworthy evidence yet.
+- `unavailable`: expected tool is missing or failing.
+
+These tool statuses can support the evidence taxonomy, but they do not replace result/verified/accepted gates.
+
+## Common Mistakes
+
+- Treating generated files as verified behavior.
+- Treating config presence as a working tool.
+- Treating a broad green test as evidence for a narrow change without coverage proof.
+- Treating an internal smoke as user acceptance for visible product behavior.
+- Updating goal status to complete when the evidence only proves one slice.

package/references/file-ownership.md

@@ -0,0 +1,107 @@
+# File Ownership And Dirty Worktree
+
+Use this when GSE work touches files in a dirty worktree, uses real subagents, simulates roles sequentially, or coordinates multiple agents, branches, worktrees, or review loops.
+
+## Core Rule
+
+Protect user work first. Then protect agent work from other agent work.
+
+A file is not safe to edit just because it is in scope. First inspect whether it already has unrelated changes, generated output, local-only edits, or another active owner.
+
+## Ownership Levels
+
+| Level | Use when | Required action |
+|---|---|---|
+| Observe | Read-only location, review, QA, code search | Do not write. Report files inspected if useful. |
+| Soft claim | One agent edits a small bounded slice | State intended files before editing and keep diff scoped. |
+| Explicit claim | Multi-agent work, broad refactor, dirty worktree, shared files | Record owner, allowed files, forbidden files, and release condition. |
+| Isolated worktree | Parallel implementation, risky experiment, long-running branch | Use a separate branch/worktree when the project supports git. |
+
+Level 1 and 2 tasks should not require formal lock files. Escalate only when collision risk is real.
+
+## Dirty Worktree Policy
+
+Before editing implementation or shared docs:
+
+1. Check project status with the safest available command, usually `git status --short` when the directory is a git repo.
+2. If the directory is not a git repo, state that git ownership evidence is unavailable and rely on file scope plus timestamps/diff if available.
+3. Identify files already modified before your work.
+4. Treat pre-existing changes as user or another agent changes unless evidence proves otherwise.
+5. Do not revert, overwrite, format, move, or delete unrelated changes.
+6. If the target file is already dirty, inspect it and merge around existing changes. Ask only if the existing change makes the requested edit ambiguous or unsafe.
+7. After editing, verify the final changed-file set matches the slice.
+
+## Claim Format
+
+Use this lightweight claim in dispatch packets, slice notes, or comments when explicit ownership is needed:
+
+For delegated or role-separated work, prefer `assets/templates/dispatch-packet.md` so the claim also includes objective, context, expected output, verification, and stop conditions.
+
+```text
+Owner:
+Purpose:
+Allowed files:
+Forbidden files:
+Expected edits:
+Verification:
+Release condition:
+```
+
+Claims should be short and local to the task. Do not create permanent process artifacts for one-off edits unless the project already requires them.
+
+## Subagent And Role Rules
+
+When real subagent tools exist:
+
+- Give each subagent a role, objective, allowed files, forbidden files, and expected output.
+- Prefer read-only locator/reviewer/QA roles for broad exploration.
+- Do not dispatch parallel builders to the same files or tightly coupled modules.
+- Require implementers to report files changed and verification run.
+- Run spec review before code-quality review when both exist.
+- Coordinator owns final integration and evidence.
+
+When no real subagent tool exists:
+
+- Execute roles sequentially in the main session.
+- Say that no real subagent dispatch occurred if the distinction matters.
+- Keep the same ownership boundaries: locator is read-only, builder writes assigned files, reviewer is read-only, QA writes evidence only.
+- Do not fake parallelism, independent review, or subagent status.
+
+## Shared File Rules
+
+Shared files include routing docs, config, package manifests, migration files, generated clients, lockfiles, schemas, shared types, and design-system primitives.
+
+For shared files:
+
+- Read surrounding patterns before editing.
+- Avoid formatting churn.
+- Keep behavior and formatting changes separate when feasible.
+- Check for generated-file policy before editing generated outputs.
+- If multiple slices need the same shared file, serialize edits through the coordinator.
+
+## Ownership Conflicts
+
+If two tasks need the same file:
+
+1. Prefer sequencing over parallel edits.
+2. If both are small and related, merge into one slice.
+3. If they are independent but touch the same file, split by branch/worktree or pick one owner.
+4. If an unexpected dirty change appears, stop destructive actions, inspect the diff, and continue only if the merge path is clear.
+5. Record unresolved conflict as a risk or blocker, not as completed work.
+
+## Verification Checklist
+
+Before claiming completion:
+
+- Intended files are the only files changed, or every extra file is explained.
+- Pre-existing dirty files were not reverted or overwritten.
+- Generated/test/output artifacts are excluded unless the project requires them.
+- Subagent work, if any, has role, allowed files, and verification evidence.
+- The evidence record names focused validation and residual risk.
+
+## Project Integration
+
+- `references/agent-roles.md` defines role responsibilities.
+- `references/operating-model.md` defines when ownership is checked in the execute loop.
+- `references/quality-gates.md` requires dirty-worktree evidence before completion.
+- `.gse/project-profile.md` should record project-specific branching, generated-file, and lockfile rules.

package/references/final-readiness.md

@@ -0,0 +1,84 @@
+# Final Readiness Matrix
+
+Use this when deciding whether GSE can be called open-source-ready, installable, and cross-host usable.
+
+This matrix is a claim boundary. It separates local verified capability from owner-required or external evidence. Do not collapse these states into a single "done" label.
+
+## Status Vocabulary
+
+- `verified`: GSE has current local evidence from scripts, records, or package/install audits.
+- `owner-required`: the owner must make or approve a decision before the claim can become accepted.
+- `external-required`: a marketplace, public registry, host runtime, security contact, CI, or other external system must provide evidence.
+- `not-claimed`: GSE deliberately does not claim this capability.
+
+## Readiness Areas
+
+The table below describes the baseline/status source for each row. The current truth is computed by `scripts/audit-final-readiness.mjs`; record-driven rows can promote from `owner-required` or `external-required` to `verified` only after accepted evidence records exist.
+
+| Area | Accepted claim requires | Status source / baseline |
+|---|---|---|
+| Skill structure | `SKILL.md`, references, scripts, assets, metadata, and validator pass | verified |
+| Project scaffold | `init-project`, project doctor, state, goal map, evidence index, close gate | verified |
+| Local install | package, install, installed-copy validation, package CLI entrypoint, and installed short CLI status command | verified |
+| npm tarball install | real local npm tarball creation, install into a clean consumer project, installed `gse` bin execution, and installed README audit | verified |
+| npm publish dry-run | npm publish dry-run keeps package identity, CLI bin metadata, required runtime files, and integrity fields without harmful metadata auto-correction | verified |
+| URL install | remote URL install, installed-copy validation, URL-installed short CLI status command, manifest integrity, and tamper rejection | verified |
+| Signing | package signing, verification, signed install, and tamper rejection | verified |
+| Open-source collaboration | README, contributing, security, support, changelog, public release metadata | verified |
+| CI workflow template | public repository workflow file plus local CI-readiness audit | verified |
+| Public CI run record | pending and accepted public CI run record mechanics | verified |
+| Public collaboration templates | issue and PR templates that require outcome, scope, evidence, risk, and claim boundaries | verified |
+| Public repository settings record | pending, verified, and accepted repository settings record mechanics | verified |
+| Public CI run | real public CI run URL or status-check evidence | record-driven external gate |
+| Public repository settings | real repository URL, issue/PR settings, branch protection, required checks, and maintainer acceptance | record-driven external gate |
+| License decision | owner-selected license or explicit not-public decision | record-driven owner gate |
+| Public security contact record | pending and accepted public security contact record mechanics | verified |
+| Public security contact | owner-approved vulnerability disclosure path | record-driven owner gate |
+| Public channel publication record | pending, registry publication, and marketplace approval record mechanics | verified |
+| Public registry publication | real public package or registry publication evidence | record-driven external gate |
+| Marketplace approval | real marketplace/catalog approval or publication evidence | record-driven external gate |
+| Portable command execution | `run-gse-command.mjs` command semantics audit | verified |
+| Host adapters | generated adapter files and compatibility matrix audit | verified |
+| Native slash command | verified host invocation record with native slash support | record-driven external gate |
+| Other host runtime invocation | verified invocation records per host | record-driven external gate |
+
+Do not read the baseline column as live status. For example, once the owner-selected license record is accepted, the audit reports `License decision` as `verified` even though the row remains an owner-gated claim type.
+
+## Audit Command
+
+```text
+node <gse-skill>/scripts/audit-final-readiness.mjs --root <gse-skill>
+```
+
+The audit must report external and owner gates as incomplete unless corresponding records exist. It is valid for the audit to pass while still reporting `owner-required` or `external-required`; passing means the matrix is honest and complete, not that every external gate is satisfied.
+
+Accepted owner/external records promote final rows only when the record contains accepted evidence and the relevant boundary proof. For example, a public CI row requires an accepted public CI run record with a successful conclusion and required-check proof; a registry row requires accepted publication evidence with registry proof; native slash command support requires a host invocation record that proves native slash-command support.
+
+Use the promotion audit to verify that this path still works:
+
+```text
+node <gse-skill>/scripts/audit-final-readiness-promotion.mjs --root <gse-skill>
+```
+
+## Acceptance Packet
+
+When owner-required or external-required rows remain, generate a handoff packet instead of burying follow-up work in prose:
+
+```text
+node <gse-skill>/scripts/generate-final-acceptance-packet.mjs --root <gse-skill> --out <gse-skill>/.gse/acceptance/final-acceptance-packet.md --force
+```
+
+The packet lists the verified local capabilities, every pending owner/external gate, the exact next evidence action, and the anti-overclaim rules. It is a continuation artifact, not acceptance by itself.
+
+## Completion Boundary
+
+GSE can be described as locally verified and release-ready for handoff when the matrix passes and the verified rows have evidence.
+
+GSE can be described as publicly accepted only after:
+
+- owner-selected license or explicit not-public decision is recorded,
+- public security contact policy is approved when public release is intended,
+- public repository settings evidence exists when a public source repository is claimed,
+- public CI run evidence exists when public CI is claimed,
+- registry or marketplace publication evidence exists when those channels are claimed,
+- native slash-command support is recorded per host before it is claimed.

package/references/forward-test.md

@@ -0,0 +1,133 @@
+# Forward Test Protocol
+
+Use this when changing GSE itself, changing reusable project scaffolds, or changing workflow rules that future agents must follow.
+
+Forward testing asks: can a future agent, fresh session, or fixture project use this change without relying on the author's memory?
+
+## Test Levels
+
+| Level | Meaning | Evidence gate | Use when |
+|---|---|---|---|
+| Structural smoke | Files, routing, audit criteria, and key text exist | verified for structure | Small reference/template/script changes |
+| Fixture forward test | A temp project or example repo uses the GSE path end to end | verified for workflow behavior | Bootstrap/profile/templates/adapters change |
+| Fresh-session forward test | A separate agent/session follows GSE with minimal context | accepted candidate | Non-trivial skill behavior, routing, multi-agent, release, recovery, or public-facing workflow changes |
+
+Do not call structural smoke a true forward-test acceptance. It proves the artifact is wired; it does not prove future-agent usability.
+
+## When Required
+
+Forward testing is required for:
+
+- New or changed scripts under `scripts/` that future projects will run.
+- Project scaffold changes under `scripts/init-project.mjs` or `assets/templates/` that affect downstream projects.
+- Router, quality gate, evidence, role, ownership, host adapter, release, recovery, or packaging rules.
+- Any change that claims a GSE capability is accepted rather than merely present or structurally verified.
+
+Forward testing is optional for:
+
+- Narrow wording edits that do not change behavior.
+- Evidence log updates.
+- Internal goal-map/current-slice status updates.
+- Small typo fixes in already tested references.
+
+Forward testing is unnecessary for:
+
+- Purely transient notes.
+- Local-only command output not used as reusable workflow evidence.
+- Work explicitly marked as draft or design judgment.
+
+## Core Scenarios
+
+Pick the smallest scenario that covers the changed behavior.
+
+### Fresh Project Bootstrap
+
+Use when bootstrap, templates, project profile, quality gates, or scaffold layout changes.
+
+Smoke:
+
+1. Create a temp project directory.
+2. Run `node <gse>/scripts/init-project.mjs --target <temp> --mode lite|standard|enterprise` as appropriate.
+3. Verify expected `.gse/` files exist.
+4. Verify rerun safety without `--force` when relevant.
+5. Record generated-file and cleanup policy.
+
+### Existing Repo Adoption
+
+Use when project-profile, discovery, dirty-worktree, tool adapters, or quality gates change.
+
+Smoke:
+
+1. Use a fixture or temp repo with representative files such as `package.json`, `AGENTS.md`, CI config, browser config, and `.env.example`.
+2. Run discovery or manual project-profile steps.
+3. Verify tool statuses stay `documented`, `verified`, `unknown`, or `unavailable` without inventing support.
+4. Verify dirty or pre-existing files are not overwritten.
+
+### Host Adapter Usage
+
+Use when `.codex/`, `.claude/`, `.agents/`, Hermes/AION-style runtime, WorkBuddy, MCP, hook, skill, or plugin adapter rules change.
+
+Smoke:
+
+1. Create or inspect a host adapter note using `assets/templates/host-adapter.md`.
+2. Confirm it points back to `.gse/` as source of truth.
+3. Mark host-specific capabilities with tool status evidence.
+4. Confirm no unsupported subagent, MCP, hook, or browser capability is claimed as verified.
+
+### Subagent Or Role Fallback
+
+Use when agent roles, dispatch packets, ownership, review, or multi-agent rules change.
+
+Smoke:
+
+1. Fill `assets/templates/dispatch-packet.md` for one locator, builder, reviewer, QA, or docs role.
+2. Include role, objective, required context, allowed files, forbidden files, expected output, verification, and stop conditions.
+3. State whether execution is real-subagent, sequential-role, or handoff-session.
+4. Verify fallback says no real delegation occurred when subagent tools are unavailable.
+5. Verify final evidence distinguishes result, verified, and accepted.
+
+## Evidence Requirements
+
+Every forward-test record should include:
+
+```text
+Forward-test level:
+Scenario:
+Changed behavior:
+Commands or inspection:
+Result evidence:
+Verification evidence:
+Accepted by:
+Residual risk:
+Next action:
+```
+
+Use `accepted by: policy` only when the applicable policy is named. Use `accepted by: fresh-session` only when a separate agent/session actually ran the path.
+
+Use `assets/templates/acceptance-execution-packet.md` when a fresh-session or owner-approved project write needs an explicit execution boundary before acceptance can be claimed.
+
+## Acceptance Rules
+
+- Structural smoke can make a slice `verified` for file/routing coverage.
+- Fixture forward test can make a workflow `verified` for the tested scenario.
+- Fresh-session forward test can support `accepted` when the fresh agent completes the intended path with only the documented GSE inputs.
+- If only structural smoke ran, record the remaining need for fixture or fresh-session testing as residual risk.
+- If a host tool is unavailable, the fallback path can be verified, but the unavailable tool capability is not verified.
+
+## Failure Handling
+
+If a forward test fails:
+
+1. Record the exact missing context, broken route, command failure, or ambiguity.
+2. Fix the smallest reusable artifact: script, template, reference, router, or gate.
+3. Re-run the same scenario.
+4. Add a learning entry only when the failure is reusable beyond the current slice.
+
+## Integration Points
+
+- `references/evidence-taxonomy.md` decides result, verified, and accepted status.
+- `references/benchmark-audit.md` decides when a GSE change needs forward-test coverage.
+- `references/quality-gates.md` applies forward-test requirements before completion.
+- `scripts/audit-project.mjs` verifies bootstrap scaffold generation and rerun safety in temporary project directories.
+- `scripts/audit-fixtures.mjs` provides a lightweight fixture audit for project-profile discovery and host-adapter/drift scenarios.
+- `.gse/evidence/YYYY-MM-DD.md` records scenario, commands, results, residual risk, and next action.

package/references/goal-map.md

@@ -0,0 +1,36 @@
+# Goal Map
+
+Goal maps keep long-running agent work from drifting.
+
+## Minimal Goal Node
+
+```yaml
+id: short-id
+title: Human-readable goal
+outcome: User or business outcome
+status: planned | in_progress | verified | accepted | blocked
+priority: P0 | P1 | P2 | P3
+dependencies: []
+acceptance: []
+evidence: []
+risks: []
+next_slice: Short next action
+last_updated: YYYY-MM-DD
+```
+
+## Update Rules
+
+- Keep the goal map short enough to guide the next session.
+- Put long logs under `.gse/evidence/` or project-specific evidence logs.
+- Update status only when evidence supports the change.
+- Show the next three slices for large projects.
+
+## Drift Checks
+
+Run a goal-map review when:
+
+- The same topic repeats without progress.
+- A module is marked done but lacks evidence.
+- The project has many commits but no visible product progress.
+- Agent sessions keep rediscovering the same context.
+