contextos-agents 2.3.1 → 2.3.2

package/.agents/core/skills/context-os/references/context-rules.md

@@ -1,68 +1,36 @@
-# Context Loading Rules
+# Context selection and budgeting
 
-## Task Type → Document Mapping
+## Inspect actual evidence
 
-| Task Type | Level 1 (Always) | Level 2 (If exists) | Level 3 (Per task) |
-| --- | --- | --- | --- |
-| **New project** | PRD, ROADMAP | ARCHITECTURE, DATABASE, API | UI, TASKS, all relevant skills |
-| **New feature** | PRD | ARCHITECTURE, API | PROJECT_GRAPH, relevant skills |
-| **Frontend** | — | ARCHITECTURE, API | UI, frontend skills |
-| **Backend** | — | ARCHITECTURE, DATABASE, API | backend skills |
-| **Database** | — | ARCHITECTURE, DATABASE | — |
-| **Bugfix** | — | — | PROJECT_GRAPH (affected module only) |
-| **Refactor** | — | ARCHITECTURE | PROJECT_GRAPH, affected skills |
-| **Review** | PRD | ARCHITECTURE | TASKS, all loaded skills |
-| **Deploy** | — | ARCHITECTURE | DEPLOYMENT, infrastructure skills |
+Supply a concrete task and affected paths to resolve. Inspect selected skills,
+reasons, risk, excluded candidates, and warnings. Select source files, callers,
+tests, relevant contracts, and active decisions manually as the task requires.
+Do not require a PRD, API document, database document, or module graph to exist.
+An absent schema change does not make database semantics irrelevant.
 
-## Skill Category → Document Mapping
+## Budget contract
 
-| Skill Category | Required Documents | Optional Documents |
-| --- | --- | --- |
-| `frontend` | UI.md, API.md | ARCHITECTURE.md |
-| `backend` | API.md, DATABASE.md | ARCHITECTURE.md |
-| `design` | UI.md | PRD.md |
-| `architecture` | ARCHITECTURE.md, DATABASE.md | PRD.md, API.md |
-| `infrastructure` | ARCHITECTURE.md | — |
-| `security` | ARCHITECTURE.md, API.md | DATABASE.md |
-| `testing` | API.md | ARCHITECTURE.md |
+The resolver estimates skill entrypoint length divided by 3.8, rounded up. It
+uses the requested positive --budget value or its current risk-tier default.
+References, tool output, system instructions, documents, and chat history are
+outside that estimate. Required safety guidance can exceed a soft budget and
+must produce an explicit overflow warning. No fixed 8000-token total or measured
+model token saving is promised.
 
-## Context Budget
+Trim irrelevant documents and select relevant sections first. Preserve user
+constraints and safety guidance. Inspect code dependencies and callers rather
+than limiting all investigations to exactly one import hop.
 
-To prevent context window overflow, apply these limits:
+## Aliases and unavailable skills
 
-| Priority | Max tokens | Content |
-| --- | --- | --- |
-| 1 (Critical) | 2000 | Current task description + relevant skill instructions |
-| 2 (Important) | 3000 | Architecture + API contracts for affected modules |
-| 3 (Context) | 2000 | Decision records + project graph (affected branch) |
-| 4 (Background) | 1000 | PRD summary + coding rules |
+context-manager resolves to context-os; gstack-roles resolves to
+engineering-workflow. The resolver avoids duplicate bodies and reports alias
+warnings. Installation and export still retain compatibility identifiers.
+Catalog skills are installed on demand; inspect unavailable-skill warnings.
 
-**Total budget: ~8000 tokens of context per task.**
+## Verification boundaries
 
-If context exceeds budget:
-
-1. Trim Level 1 docs to summaries only
-2. Load only affected sections of Level 2 docs
-3. Keep Level 3 (skills) at full detail — they contain the actual instructions
-
-## Module-Based Filtering
-
-When the Project Graph is available, use it to filter context:
-
-```
-Task: "Fix appointment reminder bug"
-  ↓
-Project Graph lookup: "reminder" → module: appointments
-  ↓
-Appointments depends_on: [patients, auth]
-  ↓
-Load only:
-  - appointments module docs
-  - auth module docs (dependency)
-  - API.md (appointments section only)
-  ↓
-Skip:
-  - patients module docs (not a dependency for this task)
-  - DATABASE.md (no schema change expected)
-  - UI.md (backend task)
-```
+compile validates manifests and builds the registry. validate checks source
+structure and sync. export --check inspects generated drift. Example tests run
+specific scenarios. None of these by itself proves live client instruction
+loading or improved model decisions.

package/.agents/core/skills/context-os/references/pipeline.md

@@ -1,119 +1,14 @@
-# Development Pipeline
-
-## The ContextOS Lifecycle
-
-```
-  ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
-  │  DEFINE  │ ──▶ │   PLAN   │ ──▶ │  BUILD   │ ──▶ │  VERIFY  │ ──▶ │  REVIEW  │ ──▶ │   SHIP   │
-  │          │     │          │     │          │     │          │     │          │     │          │
-  │ What to  │     │ How to   │     │ Write    │     │ Test &   │     │ Quality  │     │ Deploy & │
-  │ build    │     │ build it │     │ code     │     │ validate │     │ gates    │     │ document │
-  └──────────┘     └──────────┘     └──────────┘     └──────────┘     └──────────┘     └──────────┘
-       │                │                │                │                │                │
-  PRD.md           ARCHITECTURE.md  source code      tests           code review      DECISION.md
-  UI.md            DATABASE.md      components       coverage        self-review      changelog
-  ROADMAP.md       API.md           API routes       edge cases      security scan    deploy
-  PROJECT_GRAPH    TASKS.md         migrations       performance     a11y audit       release notes
-```
-
-## Stage Details
-
-### 1. DEFINE — "What are we building?"
-
-**Input:** User idea or feature request
-**Output:** PRD.md, UI.md, ROADMAP.md, PROJECT_GRAPH.md
-
-Process:
-
-1. Intent Analysis — parse the user's request
-2. Clarifying questions — fill gaps
-3. Generate PRD with clear requirements
-4. Generate UI spec if frontend is involved
-5. Create initial Project Graph
-
-**Context loaded:** None (this is the starting point)
-
-### 2. PLAN — "How will we build it?"
-
-**Input:** PRD.md
-**Output:** ARCHITECTURE.md, DATABASE.md, API.md, TASKS.md
-
-Process:
-
-1. Choose architecture based on profile + requirements
-2. Design database schema
-3. Define API contracts
-4. Break work into atomic tasks
-5. Update Project Graph with modules and features
-
-**Context loaded:** PRD.md, profiles/
-
-### 3. BUILD — "Write the code"
-
-**Input:** TASKS.md + relevant architecture docs
-**Output:** Source code, migrations, configurations
-
-Process:
-
-1. Pick next task from TASKS.md
-2. Context Compiler loads only relevant skills and docs
-3. Write code following loaded skill instructions
-4. Commit after each completed task
-5. Update Project Graph if structure changes
-
-**Context loaded:** Task-specific (via Context Manager)
-
-### 4. VERIFY — "Prove it works"
-
-**Input:** Source code
-**Output:** Tests, coverage reports
-
-Process:
-
-1. Write tests for new code
-2. Run existing tests — ensure nothing broke
-3. Check edge cases
-4. Verify performance (if applicable)
-
-**Context loaded:** Testing skills + API.md
-
-### 5. REVIEW — "Quality check"
-
-**Input:** Code changes (diff)
-**Output:** Review comments, approved changes
-
-Process:
-
-1. Self-review against coding standards
-2. Security scan (if security skill loaded)
-3. Accessibility audit (if frontend)
-4. Check against ARCHITECTURE.md — does this align?
-5. Check against Decision Records — does this contradict anything?
-
-**Context loaded:** ARCHITECTURE.md + relevant skills + decisions/
-
-### 6. SHIP — "Deploy and document"
-
-**Input:** Reviewed, tested code
-**Output:** Deployment, decision records, release notes
-
-Process:
-
-1. Record any architectural decisions made (ADR)
-2. Update ROADMAP.md — mark completed items
-3. Update TASKS.md — close completed tasks
-4. Deploy (if deployment skill loaded)
-5. Update Project Graph
-
-**Context loaded:** ROADMAP.md, TASKS.md, deployment skills
-
-## Profiles and Pipeline
-
-Different profiles customize the pipeline:
-
-| Profile | Skips | Adds |
-| --- | --- | --- |
-| **Hackathon** | REVIEW, detailed PLAN | Speed shortcuts |
-| **MVP** | Detailed REVIEW, DEPLOY | Quick iterations |
-| **Startup** | Heavy docs | Balance of speed and quality |
-| **Enterprise** | Nothing | ADR enforcement, security gates, full testing |
+# Compiler and engineering boundaries
+
+1. Inspect source manifests, declared entrypoints, overrides, and resources.
+2. Run compile to build the deterministic registry.
+3. Resolve the task with affected files and inspect risk, reasons, and warnings.
+4. Load selected entrypoints and relevant references on demand.
+5. Export supported agent projections and check drift.
+6. Run structural, example, and behavioral checks at their actual scope.
+
+For implementation use engineering-workflow's proportional lifecycle. Do not
+create a full suite of product documents or skip security review merely because
+a generic profile illustration says to do so. Profiles are runtime configuration
+from the supported profile commands and manifests, not rules interpreted from
+this skill's reference YAML files.

package/.agents/core/skills/context-os/references/project-graph.md

@@ -1,103 +1,14 @@
-# Project Graph
+# Workspace evidence graph
 
-The Project Graph is the **central nervous system** of ContextOS. It maps the entire project as a hierarchy:
+WorkspaceGraphBuilder discovers package manifests, dependency names, internal
+package links, language ecosystems, and known configuration files. The resolver
+uses nearest-package evidence to avoid unrelated monorepo stack signals. The
+graph is bounded and can report partial discovery.
 
-```
-Project
-  └── Module
-        └── Feature
-              └── Task
-                    └── File
-                          └── Skill
-```
+This graph is not a source-symbol AST, a feature/task map, or an automatic loader
+of sections from docs/PROJECT_GRAPH.md. Inspect source imports, callers, tests,
+and existing project documents explicitly for code impact analysis. A supplied
+Project Graph can help, but confirm its freshness against the current checkout.
 
-## Why Project Graph?
-
-Without a Project Graph, an AI agent sees a flat list of files. With it, the agent understands:
-
-1. **Impact analysis** — changing `calendar.ts` affects the Appointments module, which affects Patients
-2. **Scope detection** — a task touching `api/patients/` only needs Patient-related context
-3. **Skill selection** — files in `components/` need React skills, files in `api/` need backend skills
-4. **Dependency tracking** — the Calendar feature depends on the Auth module
-
-## Structure
-
-The Project Graph lives in `docs/PROJECT_GRAPH.md` and follows this format:
-
-```yaml
-project:
-  name: "DentalCRM"
-  type: crm
-
-modules:
-  patients:
-    description: "Patient management"
-    features:
-      - patient-list
-      - patient-profile
-      - medical-history
-    files:
-      - src/modules/patients/**
-    skills: [react, typescript, postgres]
-    depends_on: [auth]
-
-  appointments:
-    description: "Appointment scheduling"
-    features:
-      - appointment-calendar
-      - appointment-booking
-      - notifications
-    files:
-      - src/modules/appointments/**
-    skills: [react, typescript, postgres]
-    depends_on: [patients, auth]
-
-  auth:
-    description: "Authentication and authorization"
-    features:
-      - login
-      - registration
-      - role-management
-    files:
-      - src/modules/auth/**
-    skills: [security, typescript, jwt]
-    depends_on: []
-```
-
-## How the Context Compiler Uses It
-
-### Task: "Add a reminder notification for appointments"
-
-1. **Locate module**: `appointments`
-2. **Check dependencies**: `appointments` → `patients`, `auth`
-3. **Load relevant files**: `src/modules/appointments/**`, `src/modules/notifications/**`
-4. **Load relevant skills**: `react`, `typescript`, notification patterns
-5. **Load relevant docs**: `ARCHITECTURE.md` (notifications section), `API.md` (endpoints)
-6. **Skip irrelevant**: `DATABASE.md` (no schema change), `UI.md` (if backend-only)
-
-### Task: "Refactor the database schema"
-
-1. **Affected modules**: ALL (schema change is cross-cutting)
-2. **Load**: `DATABASE.md`, `ARCHITECTURE.md`, `PROJECT_GRAPH.md`
-3. **Show impact**: which modules/features are affected by each table change
-4. **Load skills**: `postgres` (or relevant DB skill)
-
-## Automatic Updates
-
-The Project Graph should be updated when:
-
-- New modules are added
-- Features are completed
-- File structure changes significantly
-- Dependencies between modules change
-
-Use `ctx graph` to regenerate the Project Graph from the current codebase.
-
-## Graph Queries
-
-The Context Compiler can answer questions like:
-
-- "What modules does this file belong to?"
-- "What skills are needed for this module?"
-- "What other modules will be affected if I change this?"
-- "Show me the dependency chain from here"
+Use resolve --json to inspect workspaceGraph evidence. There is no ctx graph
+command. Do not promise automatic module-graph updates or a context YAML cache.

package/.agents/core/skills/context-os/rules.yaml

@@ -1,135 +1,8 @@
-# Rule Engine
-# Conditional logic for context compilation based on project profile and task type
-
-rules:
-  # ═══════════════════════════════════════
-  # Profile-based rules
-  # ═══════════════════════════════════════
-
-  - name: mvp-minimal
-    description: MVP projects skip heavy infrastructure
-    if:
-      profile: mvp
-    then:
-      exclude_skills: [microservices, ddd, kubernetes, monitoring, cicd]
-      exclude_docs: [DEPLOYMENT.md]
-      prefer_skills: [sqlite, simple-auth, minimal-architecture]
-      max_doc_depth: 2  # Only Level 1 + Level 2
-
-  - name: enterprise-strict
-    description: Enterprise projects require full documentation and rigor
-    if:
-      profile: enterprise
-    then:
-      require_skills: [ddd, security, testing, cicd]
-      require_docs: [ARCHITECTURE.md, DATABASE.md, API.md, DECISIONS]
-      enforce_adr: true  # Every architectural decision must be recorded
-      enforce_testing: true
-      min_doc_depth: 3  # All levels required
-
-  - name: hackathon-speed
-    description: Hackathon mode — maximum speed, minimum ceremony
-    if:
-      profile: hackathon
-    then:
-      exclude_skills: [kubernetes, monitoring, cicd, ddd, microservices]
-      exclude_docs: [DEPLOYMENT.md, ROADMAP.md]
-      prefer_skills: [sqlite, simple-auth]
-      skip_review: true
-      max_doc_depth: 1  # Vision only
-
-  - name: startup-balanced
-    description: Startup balance between speed and quality
-    if:
-      profile: startup
-    then:
-      exclude_skills: [kubernetes, ddd]
-      prefer_skills: [postgres, jwt-auth, docker]
-      enforce_adr: false
-      max_doc_depth: 2
-
-  # ═══════════════════════════════════════
-  # Task-based rules
-  # ═══════════════════════════════════════
-
-  - name: frontend-task
-    description: Frontend tasks don't need database or deployment docs
-    if:
-      task_type: frontend
-    then:
-      load_docs: [UI.md, ARCHITECTURE.md, API.md]
-      skip_docs: [DATABASE.md, DEPLOYMENT.md]
-      load_skill_categories: [frontend, design]
-      skip_skill_categories: [backend, infrastructure]
-
-  - name: backend-task
-    description: Backend tasks don't need UI docs
-    if:
-      task_type: backend
-    then:
-      load_docs: [ARCHITECTURE.md, DATABASE.md, API.md]
-      skip_docs: [UI.md]
-      load_skill_categories: [backend, architecture]
-      skip_skill_categories: [design]
-
-  - name: architecture-task
-    description: Architecture tasks load everything at high level
-    if:
-      task_type: architecture
-    then:
-      load_docs: [PRD.md, ARCHITECTURE.md, DATABASE.md, API.md, PROJECT_GRAPH.md]
-      load_skill_categories: [architecture]
-      skip_skill_categories: [design]
-
-  - name: bugfix-task
-    description: Bugfixes need minimal context — focus on affected module
-    if:
-      task_type: bugfix
-    then:
-      load_docs: [PROJECT_GRAPH.md]  # Find affected module
-      max_doc_depth: 1
-      skip_docs: [PRD.md, ROADMAP.md]
-
-  - name: refactor-task
-    description: Refactoring needs architecture context
-    if:
-      task_type: refactor
-    then:
-      load_docs: [ARCHITECTURE.md, PROJECT_GRAPH.md]
-      load_skill_categories: [architecture]
-
-  # ═══════════════════════════════════════
-  # Stack-based rules
-  # ═══════════════════════════════════════
-
-  - name: react-ecosystem
-    description: React projects auto-load TypeScript
-    if:
-      skill_loaded: react
-    then:
-      auto_load: [typescript]
-      suggest: [tailwind, react-query]
-
-  - name: nextjs-ecosystem
-    description: Next.js implies React + TypeScript + SSR patterns
-    if:
-      skill_loaded: nextjs
-    then:
-      auto_load: [react, typescript]
-      suggest: [prisma, next-auth, tailwind]
-
-  - name: fastapi-ecosystem
-    description: FastAPI implies Python + Pydantic
-    if:
-      skill_loaded: fastapi
-    then:
-      auto_load: [python, pydantic]
-      suggest: [postgres, docker, testing]
-
-  - name: no-conflicts
-    description: Prevent incompatible frameworks
-    if:
-      any_loaded: [react, vue, angular, svelte]
-    then:
-      conflict_check: true
-      max_frontend_frameworks: 1
+# Reference-only illustration. The CLI does not interpret this file as policy.
+status: reference-only
+purpose: Document proportional context selection; use supported profile commands.
+principles:
+  - select relevant installed skills
+  - preserve mandatory safety guidance
+  - inspect missing-skill and budget warnings
+  - verify behavior separately from document structure

package/.agents/core/skills/engineering-workflow/EXAMPLES.md

@@ -1,57 +1,22 @@
-# engineering-workflow Examples — Anti-patterns vs ContextOS Standard
+# Workflow examples
 
-## Example 1: Handling a New Feature Request
+## Routine change
 
-### Anti-pattern: Jumping Straight to Code
+Correct a README typo, inspect the diff, and run the relevant Markdown check.
+A spec, role banner, synthetic unit test, or repeated approval adds no evidence.
 
-```text
-User: "Add a user referral system."
-Agent: Immediately creates src/referral.js, starts writing database queries, guesses schema,
-and misses requirements like rate limiting, expiry dates, and fraud prevention.
-```
+## Feature slices
 
-### Best practice: ContextOS Standard (DEFINE -> PLAN -> BUILD)
+1. Create a minimal referral claim path through storage, service, API, and UI.
+   Verify one valid claim and one rejected claim.
+2. Add expiry and repeated-claim handling through the same path. Verify both.
+3. Add the required abuse controls and relevant integration checks.
 
-```markdown
-[DOMAIN: Full-Stack] [PHASE: Define] [ROLE: Product Manager]
-Skills loaded: engineering-workflow, interview-me
+Do not split every feature into all storage first, all routes second, and all UI
+last unless the architecture or dependencies actually require that order.
 
-## Feature Spec: User Referral System
-### Why (Problem)
-Increase user acquisition through organic word-of-mouth incentives.
+## Review request
 
-### Scope
-In-Scope:
-- Unique referral code generation per registered user
-- Referral code attribution on signup
-- Credit reward trigger after first completed purchase
-Out-of-Scope:
-- Multi-tier MLM rewards
-- Cash payout integrations
-
-### Acceptance Criteria
-- [ ] Given a registered user, when visiting /referrals, then unique code is displayed.
-- [ ] Given a new user with code, when signing up, then referrer_id is stored with status 'pending'.
-```
-
----
-
-## Example 2: Atomic Task Execution in PLAN Phase
-
-### Anti-pattern: Monolithic Mega-Task
-
-```text
-Task: "Implement entire referral system end-to-end in one shot."
-Result: 15 files modified simultaneously, uncompilable intermediate state, untestable diff.
-```
-
-### Best practice: ContextOS Standard (Atomic Tasks with Test Gate)
-
-```markdown
-[DOMAIN: Full-Stack] [PHASE: Plan] [ROLE: Architect]
-Atomic Tasks:
-1. Database migration: referrals and referral_rewards tables + indexes. (Test: Migration rollback & apply)
-2. Domain service: ReferralService.createCode() and ReferralService.claimCode(). (Test: Unit tests)
-3. API route: POST /api/referrals/claim with Zod validation. (Test: Supertest integration)
-4. UI component: <ReferralCard /> with copy button. (Test: RTL component test)
-```
+Inspect the code and callers, reproduce a failure when feasible, report an
+exploit or incorrect-result scenario and its scope. A review request by itself
+is not a request to publish, message others, or rewrite the feature.

package/.agents/core/skills/engineering-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: engineering-workflow
-description: Scope implementation work, verify behavior, and report evidence using a proportional lifecycle.
+description: "Scope implementation work, verify behavior, and report evidence using a proportional lifecycle."
 ---
 
 # engineering-workflow
@@ -11,28 +11,28 @@ Define the outcome, plan substantial changes, implement, verify, review, and rep
 
 ## When to Use
 
-Implementation, debugging, reviews, and release preparation. Routine maintenance and diagnostics can proceed directly with relevant checks.
+Implementation, debugging, reviews, and release preparation. Routine maintenance and diagnostics use targeted checks.
 
 ## Rules & Patterns
 
-Establish acceptance criteria for substantial or ambiguous features. Ask only for missing decisions that affect scope or safety. An explicit implementation request authorizes ordinary reversible work. Preserve unrelated changes. Verify behavior before reporting completion. Publishing and external messages need authorization for that action.
+Establish acceptance criteria for substantial or ambiguous work. Ask only for missing decisions affecting scope, safety, or external actions. An implementation request authorizes ordinary reversible work. Inspect affected code and callers, preserve unrelated changes, and verify behavior before reporting completion. Roles are optional.
 
-Read [references/workflow.md](references/workflow.md) for detailed procedures and examples only when needed.
+Read [references/workflow.md](references/workflow.md) for procedures when needed.
 
 ## Code Examples
 
-A README typo needs an edit and relevant formatting check. An authentication feature needs access boundaries, failure cases, implementation, and behavioral verification.
+A README typo needs a small edit and formatting check. An authorization fix needs an allowed-user case and a denied-user regression.
 
 ## Validation Checklist
 
-- [ ] The requested outcome is handled.
-- [ ] Relevant verification and safety boundaries are preserved.
-- [ ] Limitations are stated.
+- [ ] The requested outcome and applicable failure cases are checked.
+- [ ] Evidence names commands, results, scope, and limitations.
+- [ ] Unrelated changes and existing authorization are preserved.
 
 ## Common Mistakes
 
-Repeated approval after authorization; unnecessary ceremonies for routine edits; treating role labels or string checks as behavioral proof.
+Repeated approval after authorization; full ceremonies for routine edits; treating headings, role labels, or schema checks as behavioral proof.
 
 ## Integration Notes
 
-Load relevant domain skills and supporting resources on demand. Compatibility identifiers remain available.
+Use security for sensitive boundaries, ponytail-mindset for implementation complexity, and context-os for compiler/configuration work. gstack-roles is a compatibility alias.

package/.agents/core/skills/engineering-workflow/TROUBLESHOOTING.md

@@ -1,19 +1,11 @@
-# engineering-workflow Troubleshooting & Common Mistakes
-
-## 1. Premature Code Generation
-
-- **Symptom**: Agent starts spitting out code blocks while the user is still clarifying requirements.
-- **Root Cause**: Failure to enforce the IRON RULE of Phase 1 (DEFINE) and Phase 2 (PLAN).
-- **Fix**: Halt code output immediately. Announce `[PHASE: Define]` or `[PHASE: Plan]` and provide the structured spec or task breakdown for user sign-off.
-
-## 2. Blast Radius Creep
-
-- **Symptom**: A simple bugfix in one module modifies 8 unrelated configuration and styling files.
-- **Root Cause**: Missing isolation boundaries and speculative cleanup.
-- **Fix**: Restrict edits strictly to files explicitly declared in the current atomic task's plan.
-
-## 3. Unverified Claims of Completion
-
-- **Symptom**: Agent reports "Task complete! Everything is working" without running tests or builds.
-- **Root Cause**: Skipping Phase 4 (VERIFY).
-- **Fix**: Always execute tests (`npm test`, validator, compiler) and quote actual terminal exit codes and outputs before declaring completion.
+# Workflow troubleshooting
+
+- Missing material requirement: inspect existing conventions, then ask for the
+  remaining decision. Existing implementation authorization remains valid.
+- Scope growth: inspect why the caller must change, update the scoped plan, and
+  preserve unrelated edits. Do not restrict a necessary fix to an obsolete list.
+- Unverified completion: run relevant behavior checks or report what remains
+  unverified. A passing document validator is not implementation evidence.
+- Excess ceremony: use the routine fast track for a typo, formatter, or diagnostic.
+- Failed gate: read the actual failure; distinguish introduced regressions from
+  pre-existing failures instead of silently dropping the gate.