@t275005746/gse 0.1.0

package/references/project-agent-workspace.md

@@ -0,0 +1,89 @@
+# Project Agent Workspace
+
+Use this when the user asks whether GSE can create a project-local directory for agent workflow files, hooks, skills, roles, LSP notes, MCP notes, plugins, and tool adapters.
+
+## Design Rule
+
+GSE owns `.gse/` as the portable layer. Tool-specific folders are adapters, not the source of truth.
+
+```text
+project-root/
+  .gse/
+    README.md
+    goal-map.md
+    quality-gates.md
+    tooling.md
+    learnings.md
+    agent-workspace.md
+    agents/
+      roles.md
+      dispatch.md
+    hooks/
+      README.md
+    skills/
+      README.md
+    mcp/
+      README.md
+    lsp/
+      README.md
+    plugins/
+      README.md
+    changes/
+    evidence/
+    templates/
+```
+
+## Why `.gse/` Instead of `.claude/` or `.codex/`
+
+- `.claude/`, `.codex/`, `.agents/`, and product-specific runtime folders can be useful, but they bind the project to one host.
+- `.gse/` is the neutral contract any agent can read.
+- Adapters may mirror or link from `.gse/`, but durable workflow decisions should remain in `.gse/`.
+
+## Directory Responsibilities
+
+| Path | Purpose | Required |
+|---|---|---|
+| `.gse/goal-map.md` | Current goals, priorities, risks, next slice | yes |
+| `.gse/quality-gates.md` | Verification and release gates | yes |
+| `.gse/tooling.md` | Available tools and optional adapters | yes |
+| `.gse/agent-workspace.md` | Map of local agent folders and host adapters | standard+ |
+| `.gse/agents/roles.md` | Role definitions and boundaries | standard+ |
+| `.gse/agents/dispatch.md` | How to delegate work when subagents exist | standard+ |
+| `.gse/hooks/README.md` | Hook ideas and host-specific hook mapping | enterprise |
+| `.gse/skills/README.md` | Project-local skill inventory and install notes | standard+ |
+| `.gse/mcp/README.md` | MCP servers, permissions, and setup notes | enterprise |
+| `.gse/lsp/README.md` | Indexing/LSP commands and symbol navigation notes | standard+ |
+| `.gse/plugins/README.md` | Optional plugins and runtime adapters | enterprise |
+
+## Host Adapter Pattern
+
+Use adapters only when the host supports them:
+
+- Codex: `.codex/`, Codex skills, MCP config, available subagent tools.
+- Claude Code: `.claude/`, commands, hooks, agents, MCP config.
+- Hermes or AION-like runtimes: runtime skills, worker adapters, memory, tool substrate.
+- WorkBuddy or other hosts: local docs, commands, MCP, index, and automation conventions.
+
+When an adapter is needed, write a short pointer from the host folder back to `.gse/` rather than duplicating the whole process.
+
+## Lessons Borrowed From Skill Repositories
+
+Verified local observations from `mattpocock/skills` snapshot:
+
+- Skills are organized by bucket, such as `engineering/` and `productivity/`.
+- It has a setup skill that configures per-repo assumptions before other skills rely on them.
+- It uses project docs such as `CONTEXT.md`, ADRs, issue tracker config, and a router skill.
+- It distinguishes user-invoked and model-invoked skills.
+
+GSE adopts the same principles at a workflow level: setup first, local context first, small composable roles, and a router-like goal map. GSE does not copy its Claude-specific plugin layout as a hard requirement.
+
+## Missing Areas To Keep Tracking
+
+- Secrets and permission boundaries for MCP/tools.
+- Cross-agent lock files or ownership rules for concurrent edits.
+- CI integration for quality gates.
+- Release and rollback playbooks.
+- Observability for long-running agent work: traces, cost, failed commands, retries.
+- Prompt/context budgets and compaction handoff format.
+- Drift audits for stale local skills, hooks, or generated docs.
+

package/references/project-bootstrap.md

@@ -0,0 +1,122 @@
+# Project Bootstrap
+
+Use this when initializing GSE in a project.
+
+Use `references/adoption-recipes.md` when choosing between fresh install, existing repo adoption, GSE update, or host adapter adoption paths.
+
+## Modes
+
+- `auto`: default mode; chooses a scaffold from project files, scripts, CI, host folders, and runtime/tooling signals.
+- `lite`: minimal workflow files for small tasks or small projects.
+- `standard`: adds project-local agent workspace files for durable agent-assisted development.
+- `enterprise`: adds hooks, MCP, plugins, release, incident, and audit placeholders for large or long-running projects.
+
+## Minimal `.gse/` Files
+
+```text
+.gse/
+  README.md
+  state.json
+  project-profile.md
+  goal-map.md
+  goals/
+    README.md
+  quality-gates.md
+  tooling.md
+  learnings.md
+  changes/
+  evidence/
+    index.jsonl
+  templates/
+```
+
+## Standard Agent Workspace Files
+
+See `project-agent-workspace.md` for responsibilities.
+
+```text
+.gse/
+  agent-workspace.md
+  agents/
+    roles.md
+    dispatch.md
+  skills/
+    README.md
+  lsp/
+    README.md
+```
+
+## Enterprise Files
+
+```text
+.gse/
+  hooks/README.md
+  mcp/README.md
+  plugins/README.md
+  release.md
+  incident-review.md
+  audit.md
+```
+
+## Host Adapter Files
+
+When `enterprise` mode is selected and host folders already exist, `init-project.mjs` can add thin adapters such as:
+
+```text
+.codex/gse-adapter.md
+.claude/gse-adapter.md
+```
+
+These files point back to `.gse/` and must not duplicate the portable goal map, quality gates, or evidence log.
+
+For new host command/pointer adapters, prefer:
+
+```bash
+node <skill-dir>/scripts/generate-command-adapter.mjs --target <project-root> --host claude|codex|hermes|workbuddy|copilot|gemini|generic|all
+```
+
+The older `.codex/gse-adapter.md` and `.claude/gse-adapter.md` files remain compatibility pointers for existing scaffold and fixture coverage.
+
+## Recommended Command
+
+```bash
+node <skill-dir>/scripts/init-project.mjs --target <project-root>
+```
+
+This uses `--mode auto`. Pass `--mode lite`, `--mode standard`, or `--mode enterprise` when the project owner wants a specific scaffold.
+
+The script should not overwrite existing files unless `--force` is passed.
+
+## Bootstrap Smoke
+
+Use this after changing scaffold behavior or before trusting a packaged GSE skill:
+
+```bash
+node <skill-dir>/scripts/audit-project.mjs --root <skill-dir>
+```
+
+This verifies `lite`, `standard`, `enterprise`, and representative `auto` scaffold selection in temporary directories and checks rerun safety. It does not certify arbitrary real repositories, package installs, CI, or fresh-session acceptance.
+
+## AGENTS.md Integration
+
+Add a short project rule only with explicit approval:
+
+```markdown
+## GSE Workflow
+
+This project follows GSE (Goal-Spec-Evidence Engineering). Start meaningful work by reading `.gse/README.md`, bind non-trivial tasks to `.gse/goal-map.md`, and finish with evidence in `.gse/evidence/` or the project-specific evidence log.
+```
+
+## Bootstrap Acceptance
+
+- `.gse/README.md` exists.
+- `.gse/state.json` exists and records mode, phase, current slice status, tool statuses, last evidence, and residual risks.
+- `.gse/project-profile.md` exists and can capture project-specific standards, commands, tools, and permissions.
+- Goal map has a North Star and Current Focus section.
+- `.gse/evidence/index.jsonl` exists and contains at least one machine-readable adoption or slice record.
+- `.gse/goals/README.md` exists so large projects can place module-level goal details outside the root goal map.
+- Quality gates list at least universal, code, UI, release, and learning gates.
+- Tooling file records available and optional tools.
+- Standard mode records project-local agent workspace files.
+- Enterprise mode records hooks, MCP, plugins, release, incident, and audit placeholders.
+- Enterprise auto mode writes compatibility host adapter files for existing `.codex/` or `.claude/` folders; command adapters for broader hosts use `generate-command-adapter.mjs`.

package/references/project-profile.md

@@ -0,0 +1,57 @@
+# Project Profile
+
+Use this when a project has its own development standards, commands, tool connections, CI, MCP servers, LSP/index setup, release process, security rules, or agent-host conventions.
+
+## Principle
+
+Project-local rules override generic GSE defaults. GSE should adapt to the project, not flatten the project into a generic workflow.
+
+## Discovery Order
+
+Read only what is relevant to the task and risk level:
+
+1. Agent rules: `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.cursorrules`, `.windsurfrules`, or host equivalents.
+2. Project docs: README, CONTRIBUTING, CODING_STANDARDS, architecture docs, ADRs, `CONTEXT.md`.
+3. Commands and scripts: `package.json`, `Makefile`, task runners, CI workflows, test config.
+4. Tooling connections: MCP config, browser/Playwright config, LSP/index config, deployment config, observability config.
+5. Secrets and permissions: `.env.example`, secret docs, write-capable tools, destructive commands.
+6. Existing GSE files: `.gse/project-profile.md`, `.gse/tooling.md`, `.gse/quality-gates.md`.
+
+Avoid reading generated output, large logs, lockfiles, caches, screenshots, or archives unless the current task needs them.
+
+## What To Capture
+
+Keep `.gse/project-profile.md` short and factual:
+
+- Product or system identity.
+- Repository type and main languages/frameworks.
+- Development commands and focused verification commands.
+- Coding standards and formatting rules.
+- Testing strategy and required gates.
+- Tool connections: MCP, LSP/index, browser automation, CI, deploy, observability.
+- Model routing: project-approved providers, model/tool ids, capability fit, cost/latency expectations, privacy limits, and fallback policy.
+- Agent host adapters: Codex, Claude Code, Hermes/AION-style runtime, WorkBuddy, or other hosts; use `references/compatibility.md` for support status labels.
+- Security and permission boundaries.
+- Release and rollback expectations.
+- Known gotchas.
+
+## Conflict Rules
+
+- User instruction in the current conversation wins.
+- Project rules beat GSE generic defaults.
+- More specific docs beat broad docs when they clearly apply to the current subsystem.
+- If two project rules conflict, surface the conflict before editing.
+- Never invent tool availability. Mark unverified connections as `unknown` until tested or documented.
+
+## Refresh Triggers
+
+Use `references/drift-audit.md` when current project facts may have diverged from recorded profile, tooling, host, release, or permission assumptions.
+
+Refresh `.gse/project-profile.md` when:
+
+- The user says a tool/config/standard exists but GSE cannot see it.
+- A command fails because the wrong package manager, shell, or service was assumed.
+- CI/test/deploy config changes.
+- New MCP, LSP, browser, worker, model, or plugin connections are added.
+- A recurring issue appears in evidence or incident reviews.
+

package/references/public-release.md

@@ -0,0 +1,174 @@
+# Public Release Metadata
+
+Use this gate when GSE, a project-local GSE scaffold, or a GSE-derived package is prepared for public GitHub, marketplace, catalog, registry, or external handoff.
+
+Public release metadata is not a substitute for legal review, maintainer approval, CI, or marketplace approval. It makes the release state auditable so agents do not claim public readiness from local tests alone.
+
+## Required Metadata
+
+Before a public release can be called accepted, record:
+
+- Release name or version.
+- Release date or intended release window.
+- Distribution channel: GitHub repository, package registry, marketplace/catalog, internal handoff, or direct archive.
+- License decision: license identifier, license file path, and who approved it.
+- Changelog or release notes path.
+- Install/update instructions path.
+- Verification commands and latest result.
+- Signing or integrity policy.
+- Public CI run: public workflow run URL, commit SHA, required checks, result, and acceptance evidence.
+- Public security contact: owner-approved disclosure path and policy update evidence.
+- Public repository settings: issues, PRs, security policy visibility, branch protection, and required checks.
+- Public channel publication: registry package, GitHub release, marketplace, or catalog evidence when any public channel is claimed.
+- Community/support channel: optional maintainer support, sponsorship, affiliate, or related-service link, if owner-approved.
+- Known risks and unsupported claims.
+- Owner acceptance or explicit reason acceptance is still pending.
+
+## License Decision
+
+GSE must not choose a license by guessing. If the project has no approved license, record `owner-required` and keep public release acceptance pending.
+
+For the GSE skill itself, the owner-approved mainstream open-source default is MIT. See `references/open-source-defaults.md`. This default does not imply public repository, CI, registry, marketplace, or host runtime acceptance until those external records exist.
+
+Minimum license record:
+
+```text
+License status: owner-required | selected | not-public
+SPDX identifier:
+License file:
+Approved by:
+Decision date:
+Notes:
+```
+
+Use `assets/templates/public-release-record.md` when a release needs a compact owner-facing decision record.
+
+Use `scripts/record-public-release.mjs` to create a project-local record without hand-editing the template:
+
+```bash
+node <skill>/scripts/record-public-release.mjs --root <skill-or-project> --license-status owner-required --json
+```
+
+For `--license-status selected`, the command requires `--spdx`, `--license-file`, `--approved-by`, `--decision-date`, and `--evidence-status accepted`. This keeps license acceptance from being implied by a partially filled record.
+
+For `--license-status not-public`, the command requires `--approved-by` and `--decision-date`. Use this when the owner explicitly decides the package is not approved for public open-source release yet.
+
+Run `scripts/audit-public-release-decision.mjs --root <skill-or-project>` to verify that the owner-required, selected-license, and not-public decision paths behave correctly. The audit uses a temporary fixture for selected-license success and does not choose a license for the real project.
+
+## Public Release Checklist
+
+Use the generated checklist when the owner needs the public-release work in execution order instead of grouped by responsibility:
+
+```bash
+node <skill>/scripts/generate-public-release-checklist.mjs --root <skill-or-project> --force --json
+node <skill>/scripts/audit-public-release-checklist.mjs --root <skill-or-project> --json
+```
+
+The checklist is a runway, not an acceptance record. It keeps the order explicit: release bundle, public repository settings, security contact, public CI, registry publication, marketplace listing, native slash-command evidence, other host runtime evidence, then final readiness audits.
+
+## Public CI Run
+
+Local CI workflow files are not proof that public CI has run. If GSE is claimed to have public CI evidence, record the real public workflow run.
+
+Use `assets/templates/public-ci-run-record.md` for a compact record, or generate one with:
+
+```bash
+node <skill>/scripts/record-public-ci-run.mjs --root <skill-or-project> --run-status pending --json
+```
+
+For `--run-status accepted`, the command requires repository URL, workflow name, workflow file, run URL, commit SHA, branch, required checks, evidence owner, evidence date, evidence URL or run id, `--run-conclusion success`, `--evidence-status accepted`, `--accepted-by`, `--accepted-at`, `--proves-public-ci-run true`, and `--proves-required-checks true`.
+
+Run `scripts/audit-public-ci-run.mjs --root <skill-or-project>` to verify pending and accepted CI run record mechanics. The audit uses temporary fixture evidence and does not run GitHub Actions.
+
+## Public Security Contact
+
+GSE must not invent a public vulnerability disclosure address. If the owner has not approved a public security contact, keep the contact status pending and do not claim public release acceptance.
+
+Use `assets/templates/public-security-contact-record.md` for a compact record, or generate one with:
+
+```bash
+node <skill>/scripts/record-public-security-contact.mjs --root <skill-or-project> --contact-status pending --json
+```
+
+For `--contact-status accepted`, the command requires a public contact type and value, owner evidence, evidence date, evidence URL or run id, `--is-public true`, `--security-policy-updated true`, `--accepted-by`, `--accepted-at`, and `--evidence-status accepted`.
+
+Run `scripts/audit-public-security-contact.mjs --root <skill-or-project>` to verify pending and accepted record mechanics. The audit uses temporary fixture evidence and does not create a real public security contact.
+
+## Public Repository Settings
+
+Public repository settings are external evidence. Local files can define the required shape, but they do not prove that a public GitHub repository has issues, pull requests, security policy visibility, branch protection, or required checks configured.
+
+Use `assets/templates/public-repository-settings-record.md` for a compact record, or generate one with:
+
+```bash
+node <skill>/scripts/record-public-repository-settings.mjs --root <skill-or-project> --settings-status pending --json
+```
+
+For `--settings-status verified`, the command requires a public repository URL, evidence owner, evidence date, evidence URL or run id, enabled issues/PRs/security policy, branch protection, required status checks, review-before-merge, conversation resolution, force-push restriction, deletion restriction, and required check names.
+
+For `--settings-status accepted`, the command also requires `--accepted-by`, `--accepted-at`, and `--evidence-status accepted`.
+
+Run `scripts/audit-public-repository-settings.mjs --root <skill-or-project>` to verify the pending, verified, and accepted record mechanics. The audit uses temporary fixture evidence and does not configure a real public repository.
+
+## Public Channel Publication
+
+Discovery metadata, local packages, release bundles, and URL-install smokes are not public publication. If GSE is claimed to be published through a registry, marketplace, catalog, or GitHub release, record the real channel evidence.
+
+Use `assets/templates/public-channel-publication-record.md` for a compact record, or generate one with:
+
+```bash
+node <skill>/scripts/record-public-channel-publication.mjs --root <skill-or-project> --publication-status pending --json
+```
+
+For `--publication-status accepted`, the command requires channel type, channel name, channel URL, version, owner evidence, evidence date, evidence URL or run id, review status `approved` or `published`, `--accepted-by`, `--accepted-at`, and `--evidence-status accepted`.
+
+For package registry claims, accepted evidence also requires `--artifact-digest` and `--proves-registry-publication true`. For marketplace or catalog claims, accepted evidence requires `--proves-marketplace-approval true`.
+
+Run `scripts/audit-public-channel-publication.mjs --root <skill-or-project>` to verify pending, registry-publication, and marketplace-approval record mechanics. The audit uses temporary fixture evidence and does not publish to a real channel.
+
+## Community And Support Links
+
+Community links are not release channels. They can help users find support or related maintainer services, but they do not prove registry publication, marketplace approval, public CI, security disclosure, or host runtime support.
+
+For GSE, GateHub (`https://gatehub.top/`) is the current owner-candidate community/support link. Use `references/community-channels.md` before adding it to a public repository, release note, or listing.
+
+## Changelog Policy
+
+Use the project convention first. If none exists, keep a `CHANGELOG.md` with:
+
+- user-facing changes,
+- operator or maintainer changes,
+- breaking changes,
+- migration and rollback notes,
+- verification evidence,
+- known limits and unsupported claims.
+
+Do not paste long command output, private reasoning, secrets, provider payloads, or screenshots into a changelog. Link to evidence files instead.
+
+## Acceptance Levels
+
+- `result`: metadata files exist but are not verified.
+- `verified`: metadata files, scripts, changelog policy, and owner-decision placeholders are structurally checked.
+- `accepted`: owner license decision, release channel, verification evidence, and required approvals are recorded.
+
+Do not mark `accepted` when the release is only locally validated.
+
+## Integration
+
+- Use `references/open-source-defaults.md` for the mainstream public release preset.
+- Use `references/community-channels.md` for optional maintainer support, sponsorship, affiliate, or related-service links.
+- Run `scripts/audit-public-release-metadata.mjs --root <skill-or-project>` before public handoff.
+- Run `scripts/audit-public-release-decision.mjs --root <skill-or-project>` before claiming release-decision mechanics are complete.
+- Use `scripts/record-public-release.mjs --root <skill-or-project>` to write the release decision record.
+- Run `scripts/audit-public-ci-run.mjs --root <skill-or-project>` before claiming public CI run record mechanics are complete.
+- Use `scripts/record-public-ci-run.mjs --root <skill-or-project>` to write public CI run evidence.
+- Run `scripts/audit-public-security-contact.mjs --root <skill-or-project>` before claiming security contact record mechanics are complete.
+- Use `scripts/record-public-security-contact.mjs --root <skill-or-project>` to write the public security contact evidence record.
+- Run `scripts/audit-public-repository-settings.mjs --root <skill-or-project>` before claiming repository settings record mechanics are complete.
+- Use `scripts/record-public-repository-settings.mjs --root <skill-or-project>` to write the repository settings evidence record.
+- Run `scripts/audit-public-channel-publication.mjs --root <skill-or-project>` before claiming public channel publication record mechanics are complete.
+- Use `scripts/record-public-channel-publication.mjs --root <skill-or-project>` to write public registry, marketplace, catalog, or release publication evidence.
+- Run `scripts/validate-gse.mjs --root <skill>` before publishing the GSE skill itself.
+- Use `references/release.md` for release-level gates and rollback guidance.
+- Use `references/release-trust.md` for signing, public key custody, and artifact trust.
+- Use `references/marketplace-discovery.md` when preparing marketplace or catalog metadata.

package/references/quality-gates.md

@@ -0,0 +1,100 @@
+# Quality Gates
+
+Pick gates by task risk.
+
+## Universal Gate
+
+- Outcome matches request.
+- Scope did not expand silently.
+- Acceptance has evidence.
+- Evidence status uses `evidence-taxonomy.md`: result, verified, or accepted.
+- Do not claim `verified` or `accepted` when evidence only proves `result`.
+- Dirty worktree contains only intended files; use `references/file-ownership.md` when ownership or pre-existing changes are unclear.
+- Final answer states evidence and remaining risk.
+- Use `references/recovery.md` when work is interrupted, verification fails, rollback/resume decisions are needed, or another agent/session must continue.
+- Use `references/review.md` when task risk requires spec compliance, code quality, architecture drift, security/privacy, regression, or evidence review.
+- Use `references/domain-quality-gates.md` when task risk involves security/privacy, performance/cost, accessibility, resilience/recovery, UI/browser, API/state, data/migration, model/tool routing, or release/operations concerns.
+- Use `references/architecture-health.md` when the task touches structural boundaries, coupling, source-of-truth drift, ownership, dependency/security risk, performance/resilience, migration, or release impact.
+- Use `references/forward-test.md` for non-trivial GSE skill, scaffold, router, role, adapter, release, recovery, or packaging changes.
+
+## Code Gates
+
+- Focused tests for changed behavior.
+- Typecheck/lint/build when relevant.
+- Regression test for bug fixes when feasible.
+- No unrelated refactors.
+
+## Gate Profiles
+
+Use the lightest gate profile that proves the claim.
+
+### Lite Gate
+
+Use for docs, scripts, copy, narrow state labels, and low-risk local helpers.
+
+- Required: one focused command, structural check, or explicit manual evidence.
+- Optional: encoding check when docs changed.
+- Avoid by default: full build, browser smoke, distribution audit, or close gate unless the change touches those surfaces.
+
+### Standard Gate
+
+Use for user-visible product slices, shared state contracts, API behavior, persistence, or cross-file workflows.
+
+- Required: focused tests for changed behavior.
+- Add one relevant integration smoke when the slice affects a visible or persisted path.
+- Build/typecheck is required when touching Next build-time code, shared TypeScript contracts, generated package shape, or release/install behavior.
+
+### Enterprise Gate
+
+Use for public release, install/update, security, migrations, cross-host support, skill/scaffold changes, or high-blast-radius architecture.
+
+- Required: focused tests plus the hard gate matching the claim.
+- Examples: distribution audit for install claims, release bundle audit for release handoff claims, browser smoke for UI reliability claims, security scan for permission/secrets claims.
+- For GSE distribution checks, use `--profile smoke` for routine package/install/CLI/integrity evidence and `--profile full` for release, handoff, or installed-copy validation claims.
+- Full validation belongs here, not on every small product slice.
+
+Gate selection should be stated in evidence when a task could reasonably look heavier than the chosen profile.
+
+Portable validation profile runner:
+
+```text
+node <gse-skill>/scripts/run-validation-profile.mjs --target <project-root> --profile lite|standard|enterprise|release
+```
+
+Use this runner when a host, user, or future agent needs a stable command instead of hand-selecting individual audit scripts.
+
+## UI Gates
+
+- Component test or browser smoke for visible behavior.
+- Screenshot or visual inspection for layout-sensitive work.
+- Loading, empty, error, success, retry, and cancelled states covered when relevant.
+
+## Agent/Product Gates
+
+- State machine transitions are explicit.
+- Stop/retry/recovery behavior is defined.
+- Tool/process traces do not reveal hidden reasoning, secrets, or raw provider payloads.
+- Short/simple chats avoid heavy workflow paths.
+
+## Release Gates
+
+Use `references/release.md` when a task affects shipping, install, upgrade, runtime compatibility, migration, rollback, changelog/release notes, or release acceptance.
+
+- Build/install smoke.
+- Migration and rollback notes.
+- Changelog or release note.
+- Known risk list.
+- Observability or incident path for risky changes.
+
+## Domain Gates
+
+Use `references/domain-quality-gates.md` to select only the domain gates that match the risk. Do not force all gates onto Lite tasks.
+
+- Security/privacy: secrets, auth, permissions, user data, provider payloads, logs, browser traces, or tool permissions.
+- Performance/cost: latency, heavy context loading, loops, model/tool routing, workers, queues, or large files.
+- Accessibility: keyboard flow, focus, forms, semantics, contrast, responsive UI, or user-facing navigation.
+- Resilience/recovery: retry, cancellation, timeout, idempotency, duplicate prevention, fallback, or state recovery.
+- UI/browser: loading, empty, error, success, streaming, routing, layout, screenshot, or browser smoke needs.
+- API/state: contracts, persistence, sessions, caches, state machines, concurrency, or idempotency.
+- Data/migration: schema, storage, generated artifacts, import/export, compatibility, rollback, or downgrade risk.
+- Model/tool routing: provider behavior, fallback, MCP, browser, subagent, tool status, permissions, or cost route.