Skip to content

impl(orchestrator): delegation execution - first-pass proposals and auto-unless-unable with structured inability returns #1292

Closed

Description

@dezren39

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) with delegation.status: "proposal-ready" + proposal{summary, detail?, proposedChanges?, at}. On approve-proposal it applies the changes as single writer and logs the approving action id in the run's actions[]; on reject-proposal{reason} it clears the proposal, returns the mode to drew, 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 an actions[] 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: whyDrew access/policy items can never enter auto (Drew's browser / Drew's authority by definition); a delegate-auto action on one is rejected via /api/actions/result naming the class.
  • No silent rot: a delegated item stays published in NEEDS DREW with mode/status/age; an item in working must reach proposal-ready, completion, or unable within 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 in actions[].
  • First real auto cycle: item resolves and expires out, OR returns unable with a tried-list; a run leaving it working past 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

Activity

  1. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  2. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    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:

  3. added
    source/humanFiled directly by a human
    priority/normalOrdinary priority (the default)
    effort/lLarge: multi-day or open-ended; expect staged check-ins
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 27, 2026
  4. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    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).

  5. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    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:

    • Visible dashboard wording is "Needs user" (intake tier), never "Needs Drew". The honesty/freshness slice in flight is applying this across the aggregator's user-visible copy.
    • The flow mirrors the fleet's 2026-10-25 label semantics: user/review = intake (the orchestrator/Muse reviews and handles what it can first — "needs a human" means Muse), and only a genuinely-user item becomes user/escalated, surfaced to Drew with Muse's read attached.
    • For NEW contract work (this program's fields/verbs): do not introduce Drew-named identifiers. Use role-based user naming (e.g. a needsUser tier / whyUser-style field naming in the spirit of the user/ label family); exact identifier spelling is an implementation detail, the principle is not. Existing published contract fields (needsDrew in orchestration.json) are legacy until a versioned contract change renames them — that migration, if done, belongs to the contract issue and must be fail-soft on both shapes like the provenance fix (fix(aggregator/orchestrator): orchestration section rejected — provenance is an object, isOrchestrationSection requires a string #1110).
    • Drew's earlier caveat stands in the background (user/ is better than his name; not a claim the naming is perfect) — but it is the operative convention, and new work follows it rather than relitigating per change.
  6. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    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.md incl. both decision updates (standing auto toggle ON for decision/missing-info/approval classes, access/policy never auto; role-based naming — new identifiers use whyUser, no new Drew-named fields; legacy needsDrew array 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.

  7. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    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.md incl. both decision updates (standing auto toggle ON for decision/missing-info/approval classes, access/policy never auto; role-based naming — new identifiers use whyUser, no new Drew-named fields; legacy needsDrew array 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.

  8. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    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; preference actions 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 action da-mvqfix7a-12aphs posted through the live dashboard path, consumed by a manually triggered pass run under the new body, applied by run orch-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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/pm-stackpm-stack (Pad/Grist) in developing-today/codeeffort/lLarge: multi-day or open-ended; expect staged check-inskind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)source/humanFiled directly by a humanstatus:done

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions