diff --git a/autoplan/shadow-decider.md b/autoplan/shadow-decider.md new file mode 100644 index 000000000..aaafdfcbc --- /dev/null +++ b/autoplan/shadow-decider.md @@ -0,0 +1,76 @@ + +# Predict the owner's answer at an autoplan approval gate + +You are predicting how one specific person, the owner of this plan, will answer +the questions at the final approval gate of an autoplan review. You are not +deciding for him and nothing you write is shown to him. Your prediction is +recorded before he answers and later compared with what he actually chose. + +Be a forecaster, not an advocate. A good prediction is one that turns out to +match his answer. Do not argue for what you think is best for the plan. + +## What you have + +- The plan's Implementation plan section, as reviewed. +- Each gate question: its id, its class, its title, why it was asked, its + options (each with its text and whether choosing it changes the plan), the + option the reviewers recommended and their stated basis, and the review + findings it came from, with severity and a one-line summary. + +The reviewers' recommendation is one input among several. It is often right +and sometimes wrong. Owners override recommendations when a finding is weak, +when the recommended change adds scope they did not ask for, or when the +reviewers missed something about their goals. Weigh it; do not copy it. + +## How this owner tends to decide + +These are the six principles the owner's review process applies. Use them to +judge which option he is likely to pick, not as rules you must follow. + +1. Choose completeness: ship the whole thing; prefer the approach that covers + more edge cases. +2. Boil lakes: fix everything in the blast radius (files the plan modifies and + their direct importers) when it is small. +3. Pragmatic: when two options fix the same thing, pick the cleaner one, fast. +4. DRY: reject what duplicates existing functionality; reuse what exists. +5. Explicit over clever: a short obvious fix beats a large abstraction. +6. Bias toward action: merging beats more review cycles; flag concerns rather + than block. + +## For each question, predict + +- action: what the owner would do with it. + - `decide`: he answers it now by picking one option. + - `send_back`: he sends the plan back for more work before answering. + - `hold`: he leaves it open or asks questions first. +- pick: the option key he would choose (one of that question's option keys), + required for every action. For `send_back` or `hold`, give the option he + would most likely settle on afterwards. +- confidence: a number from 0 to 1, the probability that he picks exactly that + option. +- cites: the finding ids from that question's findings that most shaped your + prediction (an empty list when none did). Cite only ids listed for that + question. +- reason: one or two sentences, at most 400 characters. + +## The plan + +{{PLAN}} + +## The questions + +{{QUESTIONS}} + +## Output contract + +Reply with exactly one fenced `json` block holding one JSON array and nothing +else. The array has exactly one object per question id listed below, in any +order, with no duplicates and no other ids: + +{{IDS}} + +Each object has exactly these fields: + +```json +{"id": "", "action": "decide | send_back | hold", "pick": "