|
|
@@ -32,32 +32,43 @@ Required behavior:
|
|
|
- write valuable research findings into that file as confirmed research context
|
|
|
when they are received and reconciled;
|
|
|
- draft a plan before implementation;
|
|
|
-- ask `@oracle` to review the plan and revise it until acceptable;
|
|
|
- create a phased implementation/delegation plan;
|
|
|
-- before oracle reviews, add relevant confirmed research findings and file
|
|
|
- references to the deepwork file so oracle can review the plan or phase from
|
|
|
+- before dispatch, choose a small number of coherent implementation phases from
|
|
|
+ the work's dependencies and natural delivery boundaries; do not split work
|
|
|
+ merely to reduce an Oracle review's scope;
|
|
|
+- before execution, show the user a compact overview containing only phase
|
|
|
+ titles and order, each delegated specialist with its ownership/scope, and the
|
|
|
+ total Oracle reviews with the gate after each phase and a short reason for it;
|
|
|
+- before each implementation phase, decide the execution path: what can run in
|
|
|
+ parallel, what must be sequential, which specialists to delegate to, and
|
|
|
+ whether to split the same agent into multiple bounded lanes;
|
|
|
+- after each planned phase, validate and update the deepwork file, then ask
|
|
|
+ `@oracle` to review the phase result before continuing;
|
|
|
+- before an Oracle review, add relevant confirmed research findings and file
|
|
|
+ references to the deepwork file so Oracle can assess the decision or risk from
|
|
|
accepted context instead of redoing discovery;
|
|
|
-- ask `@oracle` to review that implementation plan before execution;
|
|
|
-- after oracle review and before each implementation phase, decide the execution
|
|
|
- path: what can run in parallel, what must be sequential, which specialists to
|
|
|
- delegate to, and whether to split the same agent into multiple bounded lanes;
|
|
|
-- after each phase, validate, update the deepwork file, prepare the plan file
|
|
|
- for oracle review and ask `@oracle` to review the phase result, fix
|
|
|
- actionable issues, then continue;
|
|
|
+- triage and batch material actionable Oracle findings into one bounded
|
|
|
+ remediation pass, then validate it with focused evidence; request a follow-up
|
|
|
+ Oracle review only if that remediation changes the reviewed decision/risk or
|
|
|
+ the original concern cannot otherwise be verified;
|
|
|
- when a phase includes `@designer`, preserve designer intent across later
|
|
|
phases. Use `@fixer` only for mechanical follow-up that does not alter the
|
|
|
UI/UX;
|
|
|
- finish with final validation and a concise summary.
|
|
|
|
|
|
-## Phase Sizing
|
|
|
+## Planned Phase Reviews
|
|
|
|
|
|
-Oracle review adds time and cost, so choose phase size deliberately during
|
|
|
-implementation planning. Phases that are too large can hide bugs, missed
|
|
|
-adjustments, and architecture decisions until they are expensive to change.
|
|
|
-Phases that are too small add review overhead with little useful feedback.
|
|
|
+Oracle reviews are automatic gates between the planned implementation phases.
|
|
|
+Before dispatch, decide the phases from the task itself: its dependencies,
|
|
|
+integration boundaries, and meaningful delivery points. Record the phase order,
|
|
|
+the total review count, the review after each phase, and a short reason for each
|
|
|
+gate in the deepwork file and compact user overview.
|
|
|
|
|
|
-Balance phase size so each Oracle review happens when its findings could
|
|
|
-meaningfully improve the work that follows.
|
|
|
+Avoid micro-phases created only to make reviews smaller or cheaper. Larger,
|
|
|
+complex tasks can have broader phases, broader patches, and correspondingly
|
|
|
+broader phase reviews. The goal is a sensible number of predictable review
|
|
|
+gates, not the smallest possible review scope. Never add an extra Oracle review
|
|
|
+merely to re-confirm a mechanical fixer change.
|
|
|
|
|
|
## Designer Handoff Guardrail
|
|
|
|
|
|
@@ -109,7 +120,7 @@ capture, as applicable:
|
|
|
- current goal and understanding;
|
|
|
- researched, factual context from `@librarian` to avoid oracle doing its own
|
|
|
research;
|
|
|
-- plan drafts and oracle review notes;
|
|
|
+- plan drafts, Oracle review budget/gates, and review notes;
|
|
|
- implementation phases and status;
|
|
|
- validation results;
|
|
|
- unresolved questions, blockers, and follow-ups.
|
Alvin