codex-orchestrator 2.0.13 → 2.0.14

package/internal-workflow/skills/tickets-orchestrator/SKILL.md

@@ -22,6 +22,10 @@ Root must not implement a full child or merge ticket boundaries. A ticket that
 cannot execute from its body plus the Parent PRD is a ticket-packet defect and
 fails closed.
 
+Every child must authorize a committed product delta. Treat a transient-evidence
+or comment-only child as a ticket-packet defect: return it to `$to-tickets`
+without requesting an exception or creating an empty checkpoint.
+
 ## Authority and ownership
 
 Before work, require:

package/internal-workflow/skills/to-spec/SKILL.md

@@ -41,18 +41,26 @@ count, file count, and risk do not size a later ticket packet; Plan and
 strengthens `Risk / Proof Notes`; it does not make the PRD or solution broader.
 Omit that section when no material risk exists.
 
+Treat only user-stated requirements, repository facts, and explicitly confirmed
+technical decisions as confirmed authority. Keep agent recommendations,
+illustrative values, and possible refactors as proposals. A request to save or
+publish the plan does not confirm those proposals. Put any proposed new runtime
+owner, abstraction, or prerequisite refactor in `Decisions For Approval` for
+explicit confirmation.
+
 ## Process
 
 1. Explore the repo if needed. Use project domain language, respect relevant
    ADRs, and reuse cited `$research` artifacts. Keep unsupported external facts
    open instead of converting them into product scope.
 
-2. Sketch the seams at which the outcome will be proved. Existing seams should
-   be preferred to new ones. Use the highest seam possible. If new seams are
-   needed, propose them at the highest point you can. The fewer seams across the
-   codebase, the better; the ideal number is one. Record only seams that
-   materially define behavior, proof, or ownership, and ask the user only when
-   a seam choice changes scope, risk, or ownership.
+2. Sketch the seams at which the outcome will be proved. Prefer existing
+   task-relevant seams and use the highest applicable seam. Add a new seam only
+   when repository evidence shows that the existing owner cannot cleanly
+   implement or prove the requested behavior. Do not centralize distinct owners
+   merely to reduce seam count. Record only seams that materially define
+   behavior, proof, or ownership, and ask the user only when a seam choice
+   changes scope, risk, or ownership.
 
 3. Write the template below, then follow the requested mode. A standalone
    planning-context issue is marked `Artifact: planning-context`; it is not an
@@ -72,8 +80,9 @@ The solution to the problem, from the user's perspective.
 
 The product, behavior, scope, ownership, rollout, and risky trade-off decisions
 the user is being asked to approve. Separate confirmed decisions from open
-decisions. If implementation discovery later changes one of these decisions,
-the delivery workflow must return a decision delta instead of guessing.
+decisions under the authority rule above. If implementation discovery later
+changes one of these decisions, the delivery workflow must return a decision
+delta instead of guessing.
 
 ## Non-Obvious Consequences
 

package/internal-workflow/skills/to-spec/evals/evals.json

@@ -19,6 +19,12 @@
       "prompt": "Write a proportional PRD for this risky cross-module outcome without deciding its implementation breakdown.",
       "expected": ["preserve Decisions For Approval and Non-Obvious Consequences", "include Risk / Proof Notes because risk is material", "leave ticket count and slicing to Plan and to-tickets"],
       "forbidden": ["make user stories extremely extensive", "determine ticket count from modules, files, or risk"]
+    },
+    {
+      "id": "proposal-save-does-not-confirm-architecture",
+      "prompt": "The agent proposed a facade and prerequisite refactor, then the user said to save the plan without explicitly approving either proposal.",
+      "expected": ["keep the facade and refactor as proposals", "place any proposed runtime owner, abstraction, or prerequisite refactor in Decisions For Approval"],
+      "forbidden": ["promote the facade or refactor to a confirmed decision", "treat save or publication as architectural approval"]
     }
   ]
 }

package/internal-workflow/skills/to-tickets/SKILL.md

@@ -46,9 +46,14 @@ outcome and blocking relationship. Risk strengthens proof and review focus; it
 does not create tickets. Merge steps that share one owner, release, and
 validation path.
 
+Do not publish a child whose outcome is only transient evidence or a tracker
+comment. Resolve that discovery before compiling the executable graph, or make
+the required durable result a committed artifact.
+
 Where repository evidence proves a small prefactor is required, "Make the
 change easy, then make the easy change." Keep it inside the same vertical
 outcome unless it is independently verifiable and genuinely blocks later work.
+File size or general cleanliness alone does not justify prefactoring.
 
 ## Process
 
@@ -69,6 +74,16 @@ that discovery resolves it.
 
 ### 2. Draft executable vertical tickets
 
+Apply this **Minimum solution check** before drafting:
+
+- state the direct solution through existing owners and seams;
+- add no new service, adapter, middleware, wrapper, compatibility path, or
+  custom verifier by default;
+- add a new mechanism only for a confirmed obligation or proven failure path
+  that the direct solution cannot satisfy;
+- perform a deletion challenge: remove any proposed mechanism that can be
+  deleted without losing required behavior, an invariant, or credible proof.
+
 Each ticket must:
 
 - deliver one observable end-to-end outcome;
@@ -80,6 +95,11 @@ Each ticket must:
 - explain why the proof cannot pass while the approved claim is false;
 - declare real blockers and dependency edges.
 
+Illustrative tuning values remain illustrative unless product authority makes
+them exact. Acceptance criteria describe observable outcomes. Freeze an
+internal mechanism only when a public contract, ownership boundary, safety
+requirement, or inter-ticket dependency depends on it.
+
 Keep unresolved product decisions with the user and unresolved external or
 technical discovery in a blocking AFK/HITL ticket. If the generated ticket
 would need a later planning artifact, it is not ready to publish.
@@ -115,8 +135,9 @@ workflow owner. Do not publish any intermediate PRD.
 For the settled packet, launch exactly one fresh `standards_reviewer` without a
 history fork (`fork_context=false` on V1; `fork_turns="none"` on V2). Begin its
 brief with `Assigned role: standards_reviewer`, provide the full source authority
-and complete publish-ready packet, and require both internal lenses in the same
-review activation: source fidelity and ticket executability.
+and complete publish-ready packet, and require all three internal lenses in the
+same review activation: source fidelity, ticket executability, and minimum
+solution and scope conservation.
 
 - **Source fidelity:** every product claim, decision, scope boundary,
   consequence, and blocker is grounded in the source; no behavior or ownership
@@ -125,6 +146,12 @@ review activation: source fidelity and ticket executability.
   fresh implementation context can execute and prove from its body plus the
   Parent PRD; dependencies are real, proof observes the claim, and no later
   planning artifact is required.
+- **Minimum solution and scope conservation:** reject Speculative Generality,
+  Middle Man indirection, unsupported new or duplicate owners, proof-only
+  runtime machinery, acceptance criteria without Parent/user/repository
+  authority, and prefactors that can stay inside the real vertical outcome.
+  Prefer deletion or narrowing before adding machinery. The reviewer may not
+  introduce a new runtime mechanism merely to make proof more exhaustive.
 
 The reviewer is read-only and returns `APPROVE` or `NEEDS_WORK` with exact
 source/artifact evidence. Capture a non-empty fresh child identity and wait for

package/internal-workflow/skills/to-tickets/evals/evals.json

@@ -74,6 +74,18 @@
         "publish red migration batches as graph children",
         "create a shared red integration branch"
       ]
+    },
+    {
+      "id": "existing-owner-before-new-machinery",
+      "prompt": "Compile tickets for an outcome that the repository's existing validator and recorder can implement and prove directly.",
+      "expected": ["use the existing validator and recorder owners", "apply the deletion challenge before drafting"],
+      "forbidden": ["add a wrapper", "split a builder as preliminary cleanup", "add a custom verifier without a confirmed obligation or proven failure path"]
+    },
+    {
+      "id": "proof-gap-does-not-create-machinery",
+      "prompt": "Semantic packet review finds that one acceptance claim is stronger than the available proof seam.",
+      "expected": ["narrow the unsupported claim or use an existing proof seam", "prefer deletion or narrowing before adding machinery"],
+      "forbidden": ["automatically add middleware", "introduce a framework or runtime mechanism merely for exhaustive proof", "invent custom tooling"]
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-orchestrator",
-  "version": "2.0.13",
+  "version": "2.0.14",
   "description": "Reusable GitHub Issues runner for Codex.",
   "type": "module",
   "license": "MIT",