codex-orchestrator 2.0.11 → 2.0.13

package/internal-workflow/operations/triage/SKILL.md

@@ -1,12 +0,0 @@
-# Triage Operation
-
-Inspect the supplied issue and repository evidence without edits or external
-writes. Use the packaged
-[coding routing](../../docs/agents/coding-skill-routing.md) for the distinction
-between a direct deterministic implementation and a real execution gap. Use
-the packaged [Triage skill](../../skills/triage/SKILL.md) only for evidence
-discipline; its labels and tracker mutations are outside this operation.
-
-Return exactly one package route in `schemas/triage-route-v1.json`: direct,
-spec-required, awaiting-user for material product ambiguity, or a typed
-blocker. Technical implementation choices never require awaiting-user.

package/internal-workflow/profiles/analyst_deep.toml

@@ -1,9 +0,0 @@
-name = "analyst_deep"
-description = "Deep read-only analysis for ambiguous architecture, contracts, and root causes."
-nickname_candidates = ["Sage"]
-model = "gpt-5.6-sol"
-model_reasoning_effort = "xhigh"
-sandbox_mode = "read-only"
-developer_instructions = """
-Analyze only. Build evidence-backed conclusions and recommendations; leave final decisions and edits to the parent.
-"""

package/internal-workflow/profiles/implementer_standard.toml

@@ -1,9 +0,0 @@
-name = "implementer_standard"
-description = "Write-capable implementation worker for one approved, bounded ticket slice."
-nickname_candidates = ["Forge", "Mason", "Builder"]
-model = "gpt-5.6-sol"
-model_reasoning_effort = "medium"
-sandbox_mode = "workspace-write"
-developer_instructions = """
-Implement only the assigned approved ticket slice through its observable interface. Respect the exact write scope, tests, exclusions, and stop conditions. You are not alone in the repository: preserve unrelated and concurrent changes, never revert work you do not own, and report overlap before editing. Use behavior-first proof for behavior changes and return changed files, acceptance proof, skipped checks, risks, and blockers to the root integrator.
-"""

package/internal-workflow/profiles/proof_agent.toml

@@ -1,8 +0,0 @@
-name = "proof_agent"
-description = "Write-capable contained proof worker; Runner enforces proof-only postconditions."
-model = "gpt-5.6-sol"
-model_reasoning_effort = "high"
-sandbox_mode = "workspace-write"
-developer_instructions = """
-Prove only the frozen criteria. Write only proof evidence requested by the Runner, never product behavior, Git history, GitHub state, publication state, or credentials. Return the exact supplied JSON schema.
-"""

package/internal-workflow/profiles/reviewer_deep.toml

@@ -1,9 +0,0 @@
-name = "reviewer_deep"
-description = "Independent read-only reviewer for plans, specs, code, cleanup, and security."
-nickname_candidates = ["Atlas", "Delta", "Echo"]
-model = "gpt-5.6-sol"
-model_reasoning_effort = "high"
-sandbox_mode = "read-only"
-developer_instructions = """
-Review adversarially and exhaustively. Trace contracts, authorization, failure recovery, concurrency, and state transitions. For code, inspect every external side effect and verify asynchronous work is awaited or returned. Never edit files; return proposed fixes to the parent. Report only concrete findings with evidence, severity, confidence, and verification gaps.
-"""

package/internal-workflow/profiles/reviewer_standard.toml

@@ -1,9 +0,0 @@
-name = "reviewer_standard"
-description = "Independent read-only reviewer for medium-risk plans, specs, tickets, cleanup, and code changes."
-nickname_candidates = ["Aster", "Quill", "Vega"]
-model = "gpt-5.6-sol"
-model_reasoning_effort = "medium"
-sandbox_mode = "read-only"
-developer_instructions = """
-Review independently and proportionately. Trace the changed behavior, ownership, contracts, failure paths, and validation without expanding scope. Never edit files. Return concrete findings with evidence, severity, confidence, verification gaps, and proposed fixes to the parent.
-"""

package/internal-workflow/schemas/ambiguity-review-v1.json

@@ -1 +0,0 @@
-{"additionalProperties":false,"properties":{"candidateSha256":{"pattern":"^[a-f0-9]{64}$","type":"string"},"evidenceReviewed":{"items":{"minLength":1,"type":"string"},"type":"array"},"findings":{"items":{"minLength":1,"type":"string"},"type":"array"},"recommendation":{"minLength":1,"type":"string"},"verdict":{"enum":["approved","rejected","blocked"],"type":"string"},"version":{"const":1,"type":"integer"}},"required":["version","candidateSha256","verdict","evidenceReviewed","findings","recommendation"],"type":"object"}

package/internal-workflow/schemas/spec-author-v1.json

@@ -1 +0,0 @@
-{"additionalProperties":false,"properties":{"blockers":{"items":{"minLength":1,"type":"string"},"type":"array"},"specPath":{"type":["string","null"]},"specSha256":{"type":["string","null"]},"status":{"enum":["ready","blocked"],"type":"string"},"summary":{"minLength":1,"type":"string"},"version":{"const":1,"type":"integer"}},"required":["version","status","specPath","specSha256","summary","blockers"],"type":"object"}

package/internal-workflow/schemas/spec-review-v1.json

@@ -1,30 +0,0 @@
-{
-  "additionalProperties": false,
-  "properties": {
-    "acceptedRisks": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "acceptedBy": { "minLength": 1, "type": "string" },
-          "defectId": { "minLength": 1, "type": "string" },
-          "policy": { "minLength": 1, "type": "string" },
-          "rationale": { "minLength": 1, "type": "string" }
-        },
-        "required": ["defectId", "rationale", "policy", "acceptedBy"],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "affectedContracts": { "items": { "minLength": 1, "type": "string" }, "type": "array" },
-    "affectedDefectIds": { "items": { "minLength": 1, "type": "string" }, "type": "array" },
-    "coverage": { "items": { "minLength": 1, "type": "string" }, "type": "array" },
-    "coverageInvalidated": { "type": "boolean" },
-    "defects": { "items": { "type": "object" }, "type": "array" },
-    "mode": { "enum": ["full", "closure"], "type": "string" },
-    "reviewerSessionId": { "minLength": 1, "type": "string" },
-    "verdict": { "enum": ["approved", "needs-work", "rejected"], "type": "string" },
-    "version": { "const": 1, "type": "integer" }
-  },
-  "required": ["version", "verdict", "mode", "coverage", "defects", "reviewerSessionId", "affectedDefectIds", "affectedContracts", "coverageInvalidated", "acceptedRisks"],
-  "type": "object"
-}

package/internal-workflow/schemas/triage-route-v1.json

@@ -1 +0,0 @@
-{"type":"object","additionalProperties":false,"required":["report"],"properties":{"report":{"anyOf":[{"type":"object","additionalProperties":false,"required":["version","status","inspectedEvidence","assumptions","direct","specRequired","awaitingUser","blocker"],"properties":{"version":{"type":"integer","const":1},"status":{"type":"string","const":"direct"},"inspectedEvidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"object","additionalProperties":false,"required":["kind","location","summary"],"properties":{"kind":{"type":"string","enum":["issue","comment","code","caller","test","instruction","context","domain","adr","behavior"]},"location":{"type":"string","minLength":1,"maxLength":16384},"summary":{"type":"string","minLength":1,"maxLength":16384}}}},"assumptions":{"type":"array","minItems":0,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"direct":{"type":"object","additionalProperties":false,"required":["summary","behaviors","verification"],"properties":{"summary":{"type":"string","minLength":1,"maxLength":16384},"behaviors":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"verification":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}}}},"specRequired":{"type":"null"},"awaitingUser":{"type":"null"},"blocker":{"type":"null"}}},{"type":"object","additionalProperties":false,"required":["version","status","inspectedEvidence","assumptions","direct","specRequired","awaitingUser","blocker"],"properties":{"version":{"type":"integer","const":1},"status":{"type":"string","const":"spec-required"},"inspectedEvidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"object","additionalProperties":false,"required":["kind","location","summary"],"properties":{"kind":{"type":"string","enum":["issue","comment","code","caller","test","instruction","context","domain","adr","behavior"]},"location":{"type":"string","minLength":1,"maxLength":16384},"summary":{"type":"string","minLength":1,"maxLength":16384}}}},"assumptions":{"type":"array","minItems":0,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"direct":{"type":"null"},"specRequired":{"type":"object","additionalProperties":false,"required":["summary","complexityReasons","specMode","reviewFocus"],"properties":{"summary":{"type":"string","minLength":1,"maxLength":16384},"complexityReasons":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"specMode":{"type":"string","enum":["compact","standard"]},"reviewFocus":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}}}},"awaitingUser":{"type":"null"},"blocker":{"type":"null"}}},{"type":"object","additionalProperties":false,"required":["version","status","inspectedEvidence","assumptions","direct","specRequired","awaitingUser","blocker"],"properties":{"version":{"type":"integer","const":1},"status":{"type":"string","const":"awaiting-user"},"inspectedEvidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"object","additionalProperties":false,"required":["kind","location","summary"],"properties":{"kind":{"type":"string","enum":["issue","comment","code","caller","test","instruction","context","domain","adr","behavior"]},"location":{"type":"string","minLength":1,"maxLength":16384},"summary":{"type":"string","minLength":1,"maxLength":16384}}}},"assumptions":{"type":"array","minItems":0,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"direct":{"type":"null"},"specRequired":{"type":"null"},"awaitingUser":{"type":"object","additionalProperties":false,"required":["outcomes","absenceOfAuthorizedChoiceEvidence","recommendation","question"],"properties":{"outcomes":{"type":"array","minItems":2,"maxItems":256,"items":{"type":"object","additionalProperties":false,"required":["id","title","behaviorDelta","evidence"],"properties":{"id":{"type":"string","minLength":1,"maxLength":16384},"title":{"type":"string","minLength":1,"maxLength":16384},"behaviorDelta":{"type":"string","minLength":1,"maxLength":16384},"evidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}}}}},"absenceOfAuthorizedChoiceEvidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"recommendation":{"type":"string","minLength":1,"maxLength":16384},"question":{"type":"string","minLength":1,"maxLength":16384}}},"blocker":{"type":"null"}}},{"type":"object","additionalProperties":false,"required":["version","status","inspectedEvidence","assumptions","direct","specRequired","awaitingUser","blocker"],"properties":{"version":{"type":"integer","const":1},"status":{"type":"string","const":"blocked"},"inspectedEvidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"object","additionalProperties":false,"required":["kind","location","summary"],"properties":{"kind":{"type":"string","enum":["issue","comment","code","caller","test","instruction","context","domain","adr","behavior"]},"location":{"type":"string","minLength":1,"maxLength":16384},"summary":{"type":"string","minLength":1,"maxLength":16384}}}},"assumptions":{"type":"array","minItems":0,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}},"direct":{"type":"null"},"specRequired":{"type":"null"},"awaitingUser":{"type":"null"},"blocker":{"type":"object","additionalProperties":false,"required":["kind","code","summary","evidence"],"properties":{"kind":{"type":"string","enum":["external","safety","exhausted"]},"code":{"type":"string","minLength":1,"maxLength":16384},"summary":{"type":"string","minLength":1,"maxLength":16384},"evidence":{"type":"array","minItems":1,"maxItems":256,"items":{"type":"string","minLength":1,"maxLength":16384}}}}}}]}}}

package/internal-workflow/skills/agent-auto/SKILL.md

@@ -1,19 +0,0 @@
----
-name: agent-auto
-description: Implement one prepared GitHub issue inside the runner-owned worktree and return a typed implementation report.
----
-
-# Agent Auto
-
-Implement one issue end to end inside the prepared worktree. Treat the supplied issue snapshot, frozen acceptance criteria, repository instructions, and runner-provided output schema as authoritative.
-
-Inspect the repository, choose the smallest complete strategy, and follow the
-operation-provided package routing resources. Apply the packaged TDD skill for
-behavior changes, run focused affected validation, repair failures that are
-within the issue scope, and leave the worktree ready for Runner-owned review
-and independent acceptance proof. Do not invoke planning or review workflows:
-the Runner has already selected and persisted this implementation operation.
-
-The runner owns authorization and every external effect. Do not commit, push, open or edit a pull request, mutate GitHub labels/comments, publish packages, deploy, or use external credentials. Do not copy or print credential bytes or auth/secret paths. If completion depends on a credential, unavailable tool/service, or product decision, return the typed external blocker instead of widening authority.
-
-Return only the JSON object required by the exact output schema supplied by the runner. Do not add prose around the report and do not independently restate or modify its fields.

package/internal-workflow/skills/agent-auto/agents/openai.yaml

@@ -1,6 +0,0 @@
-interface:
-  display_name: "Agent Auto Implementation"
-  short_description: "Implement one runner-owned issue attempt"
-  default_prompt: "Follow the package-owned implementation operation and return its exact JSON report."
-policy:
-  allow_implicit_invocation: false

package/internal-workflow/skills/code-debugger/SKILL.md

@@ -1,122 +0,0 @@
----
-name: code-debugger
-description: Implement and verify an explicit or approved bug fix end-to-end. Use for fix requests or after diagnosis; not for explanation-only work, which uses `bug-root-cause-explainer`.
----
-
-# Code Debugger
-
-## Overview
-
-Treat every bug report as an engineering investigation, not a prompt to guess. Start by proving whether each reported problem is valid and still current, then narrow the failing path, patch the root cause with the smallest correct change, and verify the result before closing the task. Always plan your actions explicitly before executing them.
-
-For confirmed contract defects, apply the shared Contract Test Ledger gate at `../../docs/agents/contract-test-ledger.md`.
-
-## Activation Rule
-
-Use this skill only when the user wants implementation.
-
-For routing between bug diagnosis, feedback-loop construction, and implementation, use `../../docs/agents/bug-workflow-routing.md`.
-
-- If the user wants diagnosis, explanation, or options first, use `bug-root-cause-explainer`.
-- If the user reports a hard, flaky, performance-related, or unclear bug without a reliable feedback loop, use `diagnosing-bugs`.
-- If the user already chose a fix path, implement that path here.
-- Reviewer repairs already owned by an active authorized TDD flow stay in that flow under `bug-workflow-routing.md`; use this skill for separate fixes or ambiguous reproduction/cause/repair.
-
-## Debugging Workflow
-
-Default execution mode is inline; use `analyst_deep` only while causal or contract ambiguity remains unresolved.
-
-1. Triage every reported issue before accepting it as a bug.
-   - Do not assume a reported problem is correct, current, or reproducible.
-   - Check whether the report refers to code that has already changed, a misunderstanding of intended behavior, a stale environment, or a non-issue.
-   - Classify each item explicitly: confirmed bug, not reproducible yet, outdated, expected behavior, duplicate, or blocked.
-   - Only move to implementation once there is evidence that the issue is real.
-
-2. Define the failure precisely.
-   - Extract the actual symptom, expected behavior, affected surface, and reproduction hints from the user request, logs, screenshots, tests, or commands.
-   - Convert vague reports into a concrete statement: what is broken, where it happens, and under which input.
-
-3. Build a complete issue ledger when multiple bugs are reported.
-   - Enumerate every reported item before fixing anything.
-   - Track status for each entry (triage, reproduced, fixing, verified, invalid, blocked).
-   - Process items one by one, but keep the full ledger visible.
-
-4. Reproduce or recover a failing signal.
-   - Prefer the narrowest reliable proof: a failing test, local command, runtime log, or API response.
-   - Inspect existing running processes before starting duplicate services.
-   - If full reproduction is impossible, establish the strongest available failing signal and state what is missing.
-   - If no red-capable signal can be built for an unclear or flaky bug, switch to `diagnosing-bugs` before patching.
-
-5. Create a regression contract row only when the ledger gate passes.
-   - Record the invariant, concrete missed failure, and first regression test/proof before patching.
-   - The preferred sequence is `planned -> red -> green`: show the regression signal fails, apply the fix, then verify it passes.
-   - If no correct public seam exists, mark the ledger row `blocked` with the missing seam or fixture instead of writing an implementation-detail test by default.
-
-6. Build context before editing.
-   - Read local docs, runbooks, or feature notes first.
-   - Trace the execution path through entrypoints, callers, state writes, async boundaries, DTOs, and external integrations.
-   - Inspect nearby modules that can invalidate assumptions.
-   - If a prior `bug-root-cause-explainer` diagnosis exists, treat it as the starting point, then verify the key claim in code before changing anything.
-
-7. Identify the root cause.
-   - Separate the symptom from the defect that causes it.
-   - **Environment Check:** Always verify the versions of relevant dependencies (`package.json`, `requirements.txt`, `go.mod`, etc.). A bug might be a known issue in a specific library version.
-   - When framework or library behavior is material to the fix, consult official documentation or your knowledge base tools.
-
-8. Implement the smallest correct fix.
-   - Before editing a confirmed bug, apply `../../docs/agents/bugfix-quality-gate.md`.
-   - Fix the root cause instead of masking the symptom.
-   - Preserve existing architecture and local code patterns.
-   - Avoid unrelated refactors while debugging.
-   - Add or update a regression test when feasible.
-
-9. Verify the outcome.
-   - Run the narrowest meaningful checks: targeted tests, lint, build, or log inspection.
-   - Verify the final observable outcome, not only an intermediate flag, event, queue item, callback, or response.
-   - Compare the signal before and after the fix.
-
-10. Report with evidence.
-   - State the root cause, the fix, and exactly how it was verified.
-   - Call out anything that could not be verified and why.
-   - If the fix follows a user-approved path from `bug-root-cause-explainer`, say which path was implemented.
-
-## Operating Rules
-
-- **Chain of Thought:** Before executing any commands, reading files, or modifying code, write a `<thinking>` block outlining your immediate next steps and hypotheses.
-- **Safety Rails:** NEVER run destructive commands (e.g., `rm -rf`, `DROP TABLE`, destructive Git resets) without explicit user confirmation. For database debugging, strictly use `SELECT` or read-only transactions.
-- **Anti-Loop Mechanism:** If you fail to reproduce a bug or pass a test after 3 consecutive attempts, STOP making blind changes. Output a summary of what you tried, identify the current blocker, and explicitly ask the user for guidance or missing context.
-- Prefer repository evidence over speculation.
-- Prefer validating a report before treating it as ground truth.
-- Prefer fast text searches (like `rg` or `grep`) over broad file reads.
-- Prefer exact commands and exact failing conditions over summaries.
-- If a user report is underspecified, infer from code, tests, logs, and docs first; ask questions only when a safe next step cannot be discovered.
-- If the bug is intermittent or flaky, look for race conditions, shared mutable state, retries, timing assumptions, and missing cleanup.
-
-## Failure Modes To Check Aggressively
-
-- Wrong branch or inverted condition
-- Missing `await` or broken async ordering
-- Null, undefined, or empty-state handling
-- DTO or schema drift across module boundaries
-- Cache invalidation or stale state
-- Timezone, locale, or unit conversion errors
-- Partial writes and inconsistent side effects
-- Retry duplication or non-idempotent background work
-- Broken loading, error, or optimistic UI states
-- Incorrect assumptions about framework defaults or recent library behavior
-
-## Output Contract & Multi-Issue Response Template
-
-When the user reports multiple bugs or findings at once, present and maintain a ledger in this streamlined shape before and after implementation. Keep the table compact to prevent formatting errors, and place detailed plans below it.
-
-```md
-## Issue Ledger
-
-| # | Issue | Verdict | Status | Verification |
-|---|---|---|---|---|
-| 1 | <short restatement> | confirmed bug / outdated / duplicate / blocked | triage / reproduced / fixing / verified / blocked | <test, log, command, or n/a> |
-| 2 | <short restatement> | ... | ... | ... |
-
-### Details & Plans
-* **Issue 1:** <Plan, root cause, and next action>
-* **Issue 2:** <Plan, root cause, and next action>

package/internal-workflow/skills/code-debugger/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Code Debugger"
-  short_description: "Implement and verify an approved bug fix"
-  default_prompt: "Use $code-debugger to implement the user-approved bug fix path and verify the result. If the user wants diagnosis first, use $bug-root-cause-explainer."
-
-policy:
-  allow_implicit_invocation: true

package/internal-workflow/skills/code-review/references/bug-classes.md

@@ -1,56 +0,0 @@
-# Code Review Bug Classes
-
-Use this reference for substantial reviews and broad bug hunts.
-
-## Review Mindset
-
-- Findings first; summary second.
-- Prefer a few high-signal findings over a long speculative list.
-- Read enough surrounding code to understand the real execution path.
-- Include pre-existing bugs only when they materially affect the reviewed path.
-- Treat workaround-shaped code as a review target.
-- Treat duplicated business rules, builders, cleanup rules, normalization, cache keys, restart paths, and persistence math as likely drift vectors.
-- Treat "tests pass" as insufficient when contracts, ownership, or source-of-truth logic moved.
-- Do not stop after the edited hunk unless the change is truly trivial.
-
-## Non-Negotiable Passes
-
-Every substantial review covers:
-
-1. **Scope**: exact diff/commit/branch/files under review.
-2. **Execution path**: entrypoints, callers, callees, side effects, state writes, network/DB boundaries, cleanup.
-3. **Architecture fit**: correct owning layer, no leaky abstractions, no duplicate source of truth, no symptom patch in the wrong layer.
-4. **Invariants**: validation, authorization, ordering, idempotency, data shape, permissions, cache visibility, and lifecycle rules.
-5. **Failure modes**: empty, null, duplicate, stale, delayed, retried, timeout, cancellation, partial failure, concurrent execution.
-6. **Blast radius**: DTOs, schemas, cache keys, feature flags, config, metrics, tests, consumers, migrations, and backward compatibility.
-7. **Verification**: narrow tests/lint/build/analyzer for touched areas, or a clear note when a check cannot run.
-
-## Bug Classes To Hunt
-
-- Control-flow mistakes: wrong branch, inverted predicate, missing return, incorrect default, off-by-one, pagination errors.
-- State/lifecycle bugs: stale state, forgotten reset, double writes, orphaned cleanup, leaks, inconsistent derived state.
-- Async/concurrency bugs: missing `await`, race windows, non-idempotent retries, shared mutable state, closure mutation in retryable callbacks.
-- Partial-failure bugs: one side effect succeeds while durable follow-up fails.
-- Contract drift: DTO/schema/type mismatch, nullable changes, enum drift, serialization differences, `ObjectId`/`Date` runtime mismatch.
-- Cache bugs: stale reads, bad cache keys, cross-tenant leakage, missed invalidation, TTL mismatch.
-- Auth regressions: missing actor checks, wrong tenant scope, optional-param bypass, client-only enforcement.
-- Data correctness: timezones, DST, rounding, units, locale parsing, duplicate filtering, sort instability.
-- UI/API regressions: optimistic state not rolled back, loading/error/empty states broken, incompatible response handling.
-- Observability gaps: critical failures suppressed without logs, metrics, retries, or surfaced errors.
-- Workarounds: magic delays, one-off guards, forced ordering, duplicated normalization, cross-layer patches.
-- Architecture drift: business logic in the wrong layer, source-of-truth splits, unnecessary coupling.
-- Deep-module drift: shallow pass-through modules, hypothetical one-adapter seams, lost locality, weak leverage, or tests reaching inside the implementation instead of crossing the Module Interface.
-
-## Mandatory Questions
-
-Ask the relevant subset for each meaningful path:
-
-- What happens with empty, null, duplicated, delayed, retried, stale, or out-of-order input?
-- What happens when a dependency throws, times out, returns partial data, or returns stale data?
-- Can two executions interleave and corrupt state, leak data, or duplicate work?
-- Are validation and authorization enforced before side effects?
-- Does the change rely on a type guarantee that is weaker at runtime?
-- Do all readers and writers agree on field names, units, nullability, and semantics?
-- If state is rebuilt, cloned, merged, normalized, serialized, or persisted, are all required fields preserved?
-- Can feature flags, optional params, defaults, or fallback paths bypass intended behavior?
-- If failure happens halfway through, what durable state remains and who repairs it?

package/internal-workflow/skills/code-review/references/cleanup-lens.md

@@ -1,52 +0,0 @@
-# Cleanup Lens
-
-Use this method inside the code-review spec/standards lens. Its job is to reduce
-maintenance surface without changing required observable behavior. It is never
-a standalone gate, activation, verdict, or coverage class.
-
-## Depth
-
-- **Bounded:** inspect material additions and replacements for obvious duplicate
-  owners, obsolete paths, workaround branches, dead code, and unjustified
-  abstractions.
-- **Amplified:** when mandatory Review Focus names a concrete evidenced
-  simplification risk, inventory every material addition, replacement,
-  compatibility path, and runtime owner related to that risk. Do not amplify
-  from file count, implementation size, or review profile alone.
-
-## In Scope
-
-- duplicated logic, sources of truth, registrations, or old/new paths kept in parallel
-- dead helpers, flags, adapters, branches, comments, tests, or documentation left by the change
-- workaround-shaped conditionals, magic ordering, symptom patches, and unnecessary state
-- compatibility or fallback behavior without current repository, source-authority, or production evidence
-- new services, events/listeners, adapters, or indirection with one current consumer and only speculative reuse
-- ownership placement when moving or deleting code restores an existing owner without redesigning the system
-
-Do not turn functional correctness, security, performance, product decisions,
-missing regression proof, broad architecture redesign, or style preferences
-into cleanup findings. Route them to the applicable code-review lens.
-
-## Method
-
-Classify each material complexity decision:
-
-- `KEEP`: a current invariant requires it and evidence or a boundary proof supports it.
-- `SIMPLIFY`: required behavior can use a smaller existing seam or fewer states or branches.
-- `REMOVE`: no current behavior, authority, consumer, or compatibility evidence requires it.
-
-A one-producer/one-consumer abstraction defaults to `SIMPLIFY` unless a concrete
-lifecycle, transaction, dependency-direction, or fanout invariant requires the
-boundary. Do not request a new abstraction unless it reduces current
-duplication or restores an existing owner now.
-
-Report a finding only with exact evidence, concrete maintenance cost, and a
-behavior-preserving fix. Uncertain removal is a non-blocking follow-up. In
-amplified mode, include concise `KEEP | SIMPLIFY | REMOVE` decisions in the
-spec/standards handoff; bounded mode needs decisions only when they explain a
-finding or protected invariant.
-
-Cleanup repairs retain the same defect IDs. Medium or low cleanup repairs use coordinator verification plus affected validation. Launch affected-lens Closure
-only when the shared review protocol requires it for severity, protected
-contract impact, or invalidated mandatory coverage; add correctness whenever
-that Closure repair may alter observable behavior.

package/internal-workflow/skills/code-review/references/framework-lenses.md

@@ -1,34 +0,0 @@
-# Code Review Framework Lenses
-
-Load this reference when a framework is explicit or strongly implied by files/configs.
-
-## Next.js
-
-- Server/client component boundaries, hydration assumptions, browser APIs on server.
-- `fetch` cache modes, route segment caching, `revalidatePath`/`revalidateTag`, stale data behavior.
-- Route handlers/server actions: input validation, auth, serialization of dates/errors/nullables.
-- Loading, empty, error, navigation, optimistic update, rollback, back/refresh behavior.
-- SSR/client mismatch from locale, feature flags, sessions, params, and search params.
-
-## NestJS
-
-- Request flow through controller, guard, pipe, interceptor, service, repository, events/queues.
-- DTO validation versus runtime payload, especially transforms, enums, optionals, nested objects.
-- Server-side auth and tenant scope before side effects.
-- Transaction boundaries, partial writes, outbox/queue ordering, retry safety.
-- Exception mapping, HTTP status behavior, cache decorators, request scope, singleton mutable state, cron/queue concurrency.
-
-## Flutter
-
-- Widget lifecycle: `init`, `build`, async callbacks, `dispose`, state updates after unmount.
-- Navigation/back stack, dialog/sheet dismissal, duplicate submit from rapid taps.
-- State management transitions, stale emissions, missed listeners, dropped fields.
-- Loading, offline, empty, error, retry states.
-- Platform permissions, keyboard insets, small-screen overflow, animation/controller/stream cleanup.
-
-## Dart
-
-- Null-safety assumptions, casts, `late`, `!`, JSON parsing, generated serializers.
-- `Future`, `Stream`, timer, isolate ordering, cancellation, uncaught errors.
-- Equality, copy semantics, immutable updates, mutation during iteration.
-- Date/duration/timezone handling, numeric precision, parsing, generic runtime assumptions.

package/internal-workflow/skills/code-review/references/targeted-recipes.md

@@ -1,49 +0,0 @@
-# Code Review Targeted Recipes
-
-Load this reference when the diff shape matches one of these recurring risks.
-
-## Activation
-
-- new field or contract: run **New Field Threading**
-- transaction/retry/queue/background job: run **Retryable Persistence**
-- DTO/schema/type/persistence change: run **Runtime Contract Alignment**
-- cache or invalidation change: run **Cache Coherence**
-- server/AI/cache/fallback state merged into client state: run **State Merge Precedence**
-- preview/trace/summary/score/winner field: run **Aggregation Cardinality**
-
-## New Field Threading
-
-1. Search for the field name.
-2. Search nearby `build`, `apply`, `adjust`, `replan`, `normalize`, `merge`, `compile`, `serialize`, `clone`, and fallback helpers.
-3. Confirm the field survives primary construction, correction/replan paths, persistence reload, response serialization, and externally visible tests.
-
-## Retryable Persistence
-
-1. Read the whole transaction/retry callback.
-2. List outer-scope variables referenced inside it.
-3. Flag mutation of outer arrays, counters, iterators, derived inputs, or one-shot streams that changes behavior on retry.
-4. Compare transactional and non-transactional paths for parity.
-
-## Runtime Contract Alignment
-
-1. Compare DTO validation, internal type, persistence schema, normalization, API response shape, and frontend/state consumers.
-2. Treat `string` versus `ObjectId`, `Date` versus string, enum drift, and nested optional mismatches as review targets.
-3. Prefer boundary validation when malformed input should be rejected.
-
-## Cache Coherence
-
-1. Identify cache key inputs, tenant/user scope, feature flags, locale, and permissions.
-2. Confirm invalidation covers every write path and revalidation timing matches user-visible expectations.
-3. Check stale reads, cross-tenant leakage, and optimistic UI/cache rollback.
-
-## State Merge Precedence
-
-1. Identify precedence between user-entered state, server state, AI-generated state, fallback state, cache state, and defaults.
-2. Verify omitted fields, empty objects, `false`, `0`, or `null` cannot erase stronger user choices unless intended.
-3. Check both backend merge logic and frontend state update logic.
-
-## Aggregation Cardinality
-
-1. Determine whether source data is global, per-group, per-item, per-step, or per-tenant.
-2. Verify top-level summary/trace/score/winner fields do not collapse multiple meaningful entities into one misleading value.
-3. Treat `.find()`, first-selected, `sort()[0]`, and flat-array winner logic as suspicious when multiple groups can each have a result.

package/internal-workflow/skills/implementation-spec-maker/SKILL.md

@@ -1,107 +0,0 @@
----
-name: "implementation-spec-maker"
-description: "Turn an approved plan, implementation issue, contract-discovery task, or existing spec into the smallest deterministic implementation spec. Use when downstream coding needs an executable checklist with confirmed scope, targets, commands, contracts, validation, and review evidence; do not use for product discovery or implementation."
----
-
-# Implementation Spec Maker
-
-Create or revise an execution-ready specification for a downstream coding agent. Do not implement code or reopen approved product scope.
-
-## Core Contract
-
-- Treat the supplied plan, issue, discovery task, or existing spec as source authority.
-- Preserve approved scope, exclusions, guardrails, rejected approaches, blockers, validation, and required docs.
-- Confirm execution-critical facts from repository evidence or trusted external contracts. Never invent paths, symbols, commands, fixtures, env vars, schemas, ownership, or API behavior.
-- Produce the smallest spec another agent can execute without guessing. Save a useful `blocked` spec when a material unknown cannot be resolved.
-- Reference approved source content instead of repeating it; write only the missing execution delta.
-
-## Preflight
-
-1. Read the source authority, applicable repository instructions, and only the evidence needed to confirm targets, commands, contracts, consumers, fixtures, and validation.
-2. Build a transient evidence-backed scope delta with three facts per material requirement: approved behavior, current capability/owner/seam, and the smallest remaining implementation delta. Pass it in the reviewer capsule; persist it in the spec only when an executor needs it.
-   For a revision or conflicting authority, also compare the prior and current observable claim, mechanism/owner, source of truth, evidence unit/cardinality, and blocked/failure meaning. Any authority-driven change invalidates reused review coverage for that requirement; replacing a bad proof to match an unchanged reviewed claim does not.
-3. Treat behavior already present as `preserve + regression proof`, not new implementation. Stop with a blocked spec when an unresolved product value, copy decision, policy, or ownership choice changes the implementation; never manufacture a working default to keep drafting.
-4. Reuse valid Evidence Maps and `$research` artifacts. Refresh only claims invalidated by changed files, versions, dates, contracts, or conflicts.
-5. Read the relevant section of [source modes](references/source-modes.md). Stop or mark the spec blocked when its source-specific requirements are not satisfied.
-6. Classify and record these independent facts:
-   - `spec_mode`: `compact | full` — document and coordination density.
-   - `implementation_size`: `small | medium | large` — expected delivery shape.
-   - `review_profile`: `simple | medium | high` — consequence and uncertainty,
-     resolved through the review loop owned by `$implementation-spec-review`.
-   - `expected_repositories`: exact positive integer from approved scope.
-
-Before drafting, run a proof-compatibility check for each material outcome: the named proof must be able to observe the exact claim, at the required cardinality, and must not pass while that claim is false. Split platform, provider, tenant, region, or mode proofs whenever their mechanism, source of truth, granularity, timing/redaction, or failure semantics differ; reuse one proof only with evidence of equivalence.
-
-Do not infer one classification from another. For ticket work, `direct` returns
-to `$tdd`, `compact spec` requests compact mode, and `standard spec` asks the
-maker to choose the smallest deterministic shape. Start a standard ticket in
-compact mode and expand to full only when repository evidence proves a concrete
-ambiguity that compact form cannot remove safely.
-
-## Choose The Smallest Shape
-
-Default to `compact`, including coherent high-risk or cross-repository work, when ownership, sequencing, stop conditions, and proof fit clearly.
-
-Use `full` only when compact form would leave a concrete ambiguity in safety, contract, ownership, sequencing, validation, revision history, or multi-agent integration. Add only the conditional controls that resolve that ambiguity. Risk alone does not require a long document.
-
-Keep `execution_model: "single-agent"` unless write scopes are perfectly disjoint and one integrator contract is necessary. Never assign overlapping ownership of files, schemas, generated artifacts, migrations, source-of-truth rules, or shared contracts.
-
-## Minimum Solution Gate
-
-Before drafting slices:
-
-1. Reduce the approved outcome to required behavior, material invariants, and proof.
-2. State the direct `Minimum Solution` through existing owners, public seams, and repository patterns.
-3. Set `Added Complexity: None` unless the minimum solution cannot satisfy a named requirement or evidenced failure path.
-4. For every added mechanism, including a new service, helper, adapter, layer, schema object, transaction, retry policy, job, cache, flag, compatibility path, or coordination boundary, record the exact invariant or failure that requires it and what breaks without it.
-5. Run the deletion challenge: if removing a proposed mechanism still satisfies all approved behavior, invariants, and proof, remove it from the spec.
-6. Do not use technical detail to conceal a missing product decision. Unknown durations, thresholds, localized copy, policy defaults, and eligibility rules remain blockers when they materially shape behavior.
-
-Judge simplicity by the fewest necessary concepts, owners, states, and integration points, not by line or file count. Do not require complexity scores or alternative-solution essays.
-
-## Draft The Execution Contract
-
-Read [the spec template](references/spec-template.md) before drafting, then remove every unused placeholder and optional block.
-
-- Name exact source material, approved scope, exclusions, preconditions, confirmed targets, commands, and observable done criteria.
-- Organize behavior-changing work as narrow vertical slices. Start each slice with the first failing behavior test or exact observable proof, then implementation targets and a slice exit gate.
-- For contract-heavy behavior, use `../../docs/agents/contract-test-ledger.md` and include only material invariants with their first RED test or proof.
-- For UI/app-facing behavior, invoke `$ui-evidence-proof` and embed its task-specific workflow, expected screen state, viewport coverage, fresh artifacts, and criterion-to-artifact mapping in the relevant slice.
-- State exact manual/live proof when automation is not applicable.
-- Name one source of truth when behavior or data can drift. Reuse existing owners and public seams; invoke `$codebase-design` only when ownership or a public seam changes.
-- Add task-specific review checkpoints only when a risky slice becomes stable before later work. Otherwise assign its mandatory lenses, applicable targeted recipes, and concrete bug classes to final review coverage.
-- For medium-risk specs, rely on the normal concise `$spec-implementer` completion summary unless a task-specific deviation is needed. For high-risk specs, point `Final Handoff Requirements` to the extended `$spec-implementer` Final Risk Handoff and add only task-specific deviations; do not copy its field list.
-- Keep optional cleanup, compatibility logic, feature flags, telemetry, rollout machinery, generic fallbacks, and speculative abstractions out of the spec unless source authority or a proven failure path requires them.
-
-## Review And Save
-
-1. Save the draft at `docs/implementation-specs/YYYY-MM-DD/HHMM-<slug>.md` with temporary `status: "draft"` and `review_outcome: "Pending"` so review applies to a stable artifact path without presenting it as approved.
-2. Read `../implementation-spec-review/references/review-loop.md` and invoke
-   `$implementation-spec-review` as its Adapter. Supply the saved spec, source
-   authority, approved decisions, and evidence; do not restate its topology or
-   defect lifecycle.
-3. Apply one consolidated, scope-preserving repair batch. Before requesting any Closure, record a transient repair complexity delta containing every newly introduced endpoint, service, durable state, configuration input, schema/public contract, repository, or data owner and its existing-seam justification. Pass only that delta, repaired sections, and affected defects/contracts to Closure; do not add a separate simplification review.
-4. Follow the owner loop until it returns `Approved`, `Blocked`, or an eligible user-authorized `Waived` outcome. Respect its default review budget and rare fresh-Full triggers; do not create review rounds for ordinary coordinator-verifiable repairs.
-5. A preflight-blocked spec may be saved with zero reviews and `review_verdict: "Not run"`. Never fabricate approval or use `Not required`.
-6. Replace temporary lifecycle metadata with outcome, last Adapter verdict,
-   mandatory coverage, accepted risks, and open stable IDs. Keep pass/session
-   counts only for high, Closure, or interrupted review. Any substantive
-   post-approval edit invalidates approval until reviewed again.
-
-## Final Response
-
-Return only:
-
-```text
-Spec Status: Ready | Blocked
-Saved Path: <path>
-Execution: <single-agent | multi-agent>; <compact | full>; <small | medium | large>; <n> repository/repositories
-Review: <Approved | Blocked | Waived>; <simple | medium | high>; <coverage or gaps>
-Adapter Verdict: <Approved | Needs Work | Rejected | Not run>
-Verified Defects: <stable IDs or None>
-Accepted Risks: <stable IDs, authority, and reason or None>
-Open Defects: <stable IDs or None>
-Blockers: <unresolved blockers or None>
-```
-
-Do not repeat the specification or downstream implementation/signoff procedure in chat.

package/internal-workflow/skills/implementation-spec-maker/agents/openai.yaml

@@ -1,6 +0,0 @@
-interface:
-  display_name: "Implementation Spec Maker"
-  short_description: "Create lean deterministic implementation specs"
-  default_prompt: "Use $implementation-spec-maker only for a named execution decision or coordination gap; otherwise keep the direct route. Create the smallest deterministic spec and classify mode, size, repository count, and review risk independently."
-policy:
-  allow_implicit_invocation: true