Repository navigation
Description
Finding
Drew's requirement (2026-10-26), verbatim intent: "I should be able to pass it off to the orchestrator for a first pass and then approve that, or just say, 'Yeah, no, the orchestrator can do all this unless it defines that it's not able to.'"
Today the orchestration pass has no delegation concept: a needsDrew item is Drew's until he resolves it in chat, or it expires. There is no way for the fleet to draft a first pass for approval, and no structured way for the orchestrator to hand something back with "I cannot do this, here is why, here is what I tried, here is what I need" — inability today is silent (the item just stays, or worse, gets reclassified away).
Design: ~/workspace/pm-stack-needs-drew-actions-design-2026-10-26.md §2 (addendum to the #1184 coherence design).
Proposal — pass-side delegation execution (orchestration-pass behavior + state)
Consumes delegate / approve-proposal / reject-proposal actions from the dashboard actions store (#1152 + the /attention UI slice) and the delegation field from the publisher-contract slice:
- first-pass: on
delegate{mode:"first-pass"}, the pass does a bounded, NON-APPLYING first pass (reads what the item touches; drafts an answer/plan/proposed change set) and republishes the SAME item (same id — never a second item) withdelegation.status: "proposal-ready"+proposal{summary, detail?, proposedChanges?, at}. Onapprove-proposalit applies the changes as single writer and logs the approving action id in the run'sactions[]; onreject-proposal{reason}it clears the proposal, returns the mode todrew, and records the reason so it does not re-propose the same draft. - auto: on
delegate{mode:"auto"}the pass treats the item as its own queue work under its existing ladder/caps/measurement gate. Success → the item expires out with anactions[]record. The only return path is structured inability:delegation.status: "unable"+unable{reason, whatItTried[≥1], whatItNeeds, at}republished on the same item in NEEDS DREW. Silent returns and quiet reclassification to NEEDS ORCHESTRATOR are contract violations. - Hard exclusions:
whyDrewaccess/policyitems can never enter auto (Drew's browser / Drew's authority by definition); a delegate-auto action on one is rejected via/api/actions/resultnaming the class. - No silent rot: a delegated item stays published in NEEDS DREW with mode/status/age; an item in
workingmust reachproposal-ready, completion, orunablewithin 2 runs — enforced by the publisher self-check (contract slice), executed here. - Dismissals recorded in orchestrator-state with the §1.5 resurface rule (new material fact, cited, or it stays out).
DECISION PROPOSED in the design (wants Drew's confirmation): auto is per-item explicit opt-in; the pass may SUGGEST auto via recommendedAction but never set it; a standing "default to auto" toggle is designed but off until Drew turns it on.
Acceptance
- First real first-pass cycle evidences in the run log: item delegated from the dashboard → returns
proposal-ready→ approval applies it → item expires out with the action id inactions[]. - First real auto cycle: item resolves and expires out, OR returns
unablewith a tried-list; a run leaving itworkingpast the bound fails the self-check. - Rejection path: delegate-auto on an access/policy item produces a rejected action result naming the class; the item never enters auto.
- No delegated item ever appears twice in a tier or disappears without an outcome.
Refs: #1184 (epic), #1152 (actions consumption), #1148 (no-silent-decay principle). Design: pm-stack-needs-drew-actions-design-2026-10-26.md §2.
Acceptance criteria
- A needsDrew item can be delegated in two modes — first-pass-then-approve and auto-unless-unable — consuming the
delegatecontract from design+impl(orchestrator/aggregator): needsDrew item contract - whyDrew class, structured options[], survey questions[], delegation state #1290, and the item's delegation state is visible wherever the item renders. - First-pass mode: the orchestrator drafts a proposal and nothing applies until Drew approves it (proposal handling per impl(aggregator/orchestrator): proposal review state handling - proposal identity, supersede/expiry races, cross-surface counts #1293).
- Auto-unless-unable mode: the orchestrator completes the item end-to-end, or returns a structured inability: what it cannot do, what it tried, and what it needs — inability is never silent (no quiet reclassification, no item just staying).
- A delegated run is auditable after the fact: the pass records what it did or why it could not.
Activity
developing-today commentedon Oct 27, 2026
CODE-415
dezren39 commentedon Oct 27, 2026
DECISION — Drew, 2026-10-27 00:31 CDT: the standing auto toggle is ON.
Drew selected (options widget, dashboard-status chat): "Standing auto toggle ON for decision/info/approval items (access & policy always stay mine)".
What this means for implementation:
whyDrew=decision,missing-info, orapprovaldefault to delegation modeauto— the orchestrator proceeds end-to-end and returns the item ONLY with a structured inability declaration (reason / what it tried / what it needs).whyDrew=accessorpolicyNEVER enters auto under any setting — those always stay Drew's.dezren39 commentedon Oct 27, 2026
Intake review
Fleet monitor intake pass (protocol §5), 2026-10-27.
Still live: verified this run — issue is OPEN, no merged PR references or closes it (0 closing-PR references), and it was filed within the last day, so nothing has had time to supersede it.
Related: Design: pm-stack-needs-drew-actions-design-2026-10-26.md §2. Consumes #1290 (contract); proposal state races owned by #1293; UI in #1291.
Notes / risks: Drew's requirement verbatim in the body — this is the pass-side behavior slice. Effort/l: orchestration-pass behavior + state + the inability pathway is the largest slice of the set. Risk: an auto mode that acts beyond the item's scope — the structured inability return is the safety valve and must be the default on uncertainty.
Suggested approach: Suggested approach: delegation state machine on the item contract first, first-pass mode end-to-end, then auto mode gated on the inability pathway working.
Labels normalized this pass; acceptance criteria appended to the body (original text preserved verbatim above it).
dezren39 commentedon Oct 27, 2026
Naming + semantics update — Drew, 2026-10-27 01:05 CDT: "please continue and handle all updates, Needs User user/escalated and so on."
Drew directed that the role-based naming be handled across the board, resolving the open naming note on this program:
dezren39 commentedon Oct 27, 2026
Agent note — pickup (needs-user action layer build). Picked up as part of the #1290–#1293 slice on top of the landed triage write path (PR #1346/#1350, main
f9c9ffdb, 228 tests). Spec:pm-stack-needs-drew-actions-design-2026-10-26.mdincl. both decision updates (standing auto toggle ON for decision/missing-info/approval classes, access/policy never auto; role-based naming — new identifiers usewhyUser, no new Drew-named fields; legacyneedsDrewarray name untouched). Sequencing: contract → UI → consumer (orchestration-pass cron step) → seam hardening. Self-merge per PR when CI green; deploy + bounded live proof (first-pass only, no approval, no live auto execution) at the end.dezren39 commentedon Oct 27, 2026
Agent note — pickup (needs-user action layer build). Picked up as part of the #1290–#1293 slice on top of the landed triage write path (PR #1346/#1350, main
f9c9ffdb, 228 tests). Spec:pm-stack-needs-drew-actions-design-2026-10-26.mdincl. both decision updates (standing auto toggle ON for decision/missing-info/approval classes, access/policy never auto; role-based naming — new identifiers usewhyUser, no new Drew-named fields; legacyneedsDrewarray name untouched). Sequencing: contract → UI → consumer (orchestration-pass cron step) → seam hardening. Self-merge per PR when CI green; deploy + bounded live proof (first-pass only, no approval, no live auto execution) at the end.dezren39 commentedon Oct 27, 2026
Agent note — complete. Orchestrator delegation execution is live in the orchestration-pass body (DELEGATION EXECUTION step, added under the cron-edit discipline: pre-edit body captured two ways — projection extract sha256
b2ff2a4d…+ cron.view — asserted exact-match edits only; post-edit stored body byte-verified against the mechanically built expectation, the sole delta being one blank line before PUBLISH + REPORT:; every unchanged old line verified present verbatim except the two deliberately replaced).Semantics now in the pass: why-class + item contract publishing; the standing preference (initial record = the 2026-10-27 decision, auto ON for decision/missing-info/approval;
preferenceactions supersede it); first-pass drafting WITHOUT applying, published as a proposal with (item id, runId, updatedAt) identity; auto as the pass's own queue work under its ladder/caps/gate, returning ONLY via the structured inability {reason, whatItTried[≥1], whatItNeeds}; approve/reject with exact identity match (mismatch → rejected "proposal superseded/withdrawn"); the 2-run deadline + 48h proposal expiry enforced in the pass's pre-publish self-check (tied to #1148 — noted there); access/policy never auto, with the class named in the rejection.LIVE PROOF (bounded, as specified): item
queue-discovery-design-pick— delegate first-pass actionda-mvqfix7a-12aphsposted through the live dashboard path, consumed by a manually triggered pass run under the new body, applied by runorch-2026-10-27T09:05:40Z("delegate first-pass applied: drafted queue-discovery analysis recommending producer-enqueue + reconciliation…"). The published proposal (recommendation + evidence detail, plus 3 options and 1 survey question the pass added) renders on /attention with Approve/Reject controls. It was NOT approved — it is pending for the user now. Auto execution was NOT run as a live test: the auto evidence is the pass's published defaulting in the same run (eligible classes auto/idle, every access item user) + the aggregator fallback defaulting observed on the prior section + the contract fixtures.