Standalone analysis commissioned by Drew, 2026-11-01: full comparison of DeepSeek's dsh-superagent-prototype against our repo-health fleet — same-path check, concept mapping, adoptable ideas (fed into #3424 and #3418), and the deliberate differences we keep. Full text below; also sent to Aster for review.

DeepSeek dsh-superagent-prototype vs. our repo-health fleet — comparison & adoptable ideas

Date: 2026-11-01. Scope: whole system, not just code#3424.
Sources read: their docs/000-philosophy.md, 001-domain.md, 002-authorization.md,
003-execution.md, 004-prompts.md, 005-panel.md, 007-architecture.md
(006-deployment / 008-cookbook not read). Ours: goal GOAL.md, code#3424 + newest
comments, code#3418, opencode#1014 + directive comments, fleet instruction files,
standing Drew rules (merge authority, quota doctrine, decision surfacing).
Every claim about their system cites the doc it came from. Nothing posted to GitHub.

1. Their core concepts (compact)

Philosophy / operating stance

• Prime metric: take as little human attention as possible, give as much value as
  possible; every message, notification, question, setting, and panel element must
  earn its attention cost or be removed (000-philosophy).
• Acts only when asked, or when a written rule allows it; unrequested work starts
  in a record-only mode (000-philosophy, 002-authorization).
• Speaks only when a person must act or can use a result; confirms a request once,
  stays quiet while working (000-philosophy, 004-prompts).
• One concrete question at a time, in structured form (000-philosophy; implemented
  as the Report's structured question field, 001-domain / 003-execution).
• Stops by impact, not effort: local change → reviewable result; a change needing
  a design decision stops with a clear question (000-philosophy).
• Honest reporting: drafts marked unfinished, failures reported as failures,
  limits never bypassed to avoid asking (000-philosophy, 004-prompts).

Domain (001-domain)

• Source — an event stream (kind + instance config); holds its read position and
  bot identity; drops the bot's own messages before they enter the domain.
• Trigger — one immutable event; the unit of audit and idempotence (accepting it
  twice creates one Ticket).
• Thread — Triggers in time order; at most one Eval at a time; holds
  Subscriptions and Decision history.
• Eval — stateless judgement on a batch of Triggers in two layers: a deterministic
  Gate, then model Assessment. Output is a Decision: accept / stop / ignore /
  unavailable.
• Mandate — what an accept grants: Policy version, scope, strength, matched
  rules, sender identity. Immutable; wider scope = new Ticket; only a person's
  stop withdraws it; revalidated against current Policy before an ended Ticket
  resumes.
• Ticket — the unit of authorized work; open → ended → resumable by a person's
  message on its Threads; defines its own state, independent of the Executor.
• Assignment — binding of a Ticket to one Executor instance; a Ticket has several
  over time; pending → running → ended independently of the Ticket.
• Subscription — many-to-many Ticket↔Thread relation; fan-out delivers Thread
  messages to live Tickets as context with no authority check; context-only
  subscriptions lend context but no authority and do not resume.
• Correlation — relation between Threads sharing a Trigger; adds context, never
  routes.
• Channel — the write side of a Thread (acks, replies, PRs, review replies).
• Policy — versioned assessment rules + per-Source parts (allowed list, admission
  table, bot list); a Policy change notifies affected live Tickets but does not
  revoke their Mandates.
• Attention — a structured question on a Ticket waiting for a person's answer.
• Disposition — the record of where each Trigger went (filtered / evaluated /
  fanned out / handed back / answered).
• Report — the Executor's structured state report to its Ticket: progress /
  waiting / ready / blocked / failed / dropped, plus an optional question.
• Explicitly rejected concepts (001-domain "Rejected concepts"): cross-Source
  identity mapping, Eval scheduling its own delayed Triggers (waiting belongs to
  Sources), waiting/revoked Eval states, one-live-Ticket-per-Thread, Ticket state
  following the Executor session, an Executor declaring a person asked to stop,
  cancelling running Tickets on Policy change, inferring "waiting on a person"
  from free-text reports.

Authorization (002-authorization)

• Strength: explicit (allowed person addresses the agent, or follows up on a
  Thread with a Ticket) vs inferred (bot on the bot list, unlisted follow-up,
  admission-cell candidates). Bots can never make explicit requests or stop work.
• Admission table per Source: rows = receiving scopes, cells decide
  explicit / inferred / ignore by sender membership × addressed-or-not.
• Accept mode per Policy: off / observe (default; inferred accepts are
  recorded as "would accept" and nothing starts) / auto. Explicit requests
  work in every mode. Proactive accept requires ≥1 matching rule, and every
  enabled rule is judged exactly once per assessment.
• Follow-up ownership: a message on a Ticket's Thread is owned by that Ticket's
  Executor (no Eval); the Executor handles it in-scope or hands it back once,
  with a reason; only when no Ticket owns it does it go to fresh Eval. The main
  Session may act on an owned follow-up only to stop work.
• Revalidation before resume: an ended Ticket's Mandate is checked against
  today's Policy (mode, rules still enabled, sender still listed, bot still
  listed); failure = the Ticket stays ended and its waiting messages re-enter
  the intake path as unowned.
• Eval failure discipline: an expired Eval requeues twice, then records
  unavailable; assessment failure also records unavailable; Policy change
  mid-Eval records unavailable and requeues under the new version immediately.

Execution (003-execution)

• Ticket stages are derived, not stored: a precedence table (first match wins)
  computes the stage from facts — input-undelivered, has-Attention, latest
  Report ready / blocked / failed, queued, idle (waiting), working. A person/*
  stage means the Ticket cannot continue without a human.
• One Executor Session + one directory per Ticket (worker-<ticket id>);
  prepare command (typically git worktree) runs once before the first
  Assignment; a PR belongs to the Ticket when its branch's last segment matches
  the Ticket's short name.
• Worker slots: a Ticket holds a slot through background work; background work
  gets ≤30 min after turn end, then shell jobs are killed and the Ticket reports
  waiting with which jobs were killed. One extra slot beyond the concurrency
  limit is reserved for a person's message or a status request, and human wakes
  take priority over new launches.
• Blocked/failed hold: on a blocked/failed Report the Ticket takes no
  automatic Input (CI/bot messages are recorded, not delivered); transient
  provider/network failures (408/429/5xx, refused/reset/timeout) retry 3× with
  growing backoff before the hold; a person's message, a non-blocked Report, or
  a manual Retry ends the hold.
• Stored work: side effects are stored first, executed after (transactional
  outbox); retries with doubling backoff; a kind of work surfaces as a system
  problem only after 3 consecutive failures of an item.
• Restart recovery: interrupted Assignments restart with a recovery note ("check
  directory, git history and GitHub before repeating any outside action"),
  oldest Ticket first; read/unread Input accounting survives restarts, and a
  replacement Assignment re-receives exactly the Inputs the old one never took.
• Pause processing: stops dispatch, Evals, deliveries and replies; Sources keep
  recording Triggers; running turns are not interrupted; Eval deadlines shift
  by the pause length.
• Merge governance is prompt text ("Delivery requirements"), not host logic:
  the agent account never enables auto-merge (attribution goes to whoever
  enabled it); default rule allows auto-merge only for the Ticket's own PR,
  ready, approvals covering the head commit, <200 changed lines.
• A Ticket following PRs ends when none of the PRs it opened remain open (or all
  followed PRs closed); outcome = the last relevant close; it keeps its
  Subscriptions afterwards so a later human comment resumes it.

Panel (005-panel)

• The panel answers three questions in order: (1) does anything need me now?
  (2) is the system healthy and doing the right things? (3) what is the history
  of one piece of work, Trigger → Eval → Ticket?
• Overview lists Tickets needing action first; a healthy state takes no space;
  every count equals the length of the list it links to; a label says whom a
  row waits for and what it needs, not an internal status code; problems must
  be actionable (a one-off network error is not enough); rows needing a person
  offer their action (Retry, stop, dismiss, evaluate-again) directly.
• An unavailable Decision asks for human attention only when <24h old, still
  the latest on its Thread, undismissed, and the Thread is neither queued nor
  evaluating.

Prompts (004-prompts)

• Prompt assembly has a fixed precedence ladder: (1) facts enforced by tools/
  host, (2) built-in + generated sections as overridden, (3) a proactive
  Ticket's matched-rule requirements for that Ticket only, (4) team sections
  and skills, (5) outside text — data, never authorization.
• The Policy section is regenerated from settings on every model request and
  placed last, so a Policy change leaves the preceding prompt text unchanged.
• Prompts and settings are immutable versions with base-revision optimistic
  concurrency; a conflicting save is refused without discarding the draft;
  Sessions read the latest version on every request, even mid-turn; an override
  identical to the default is deleted so the part follows future defaults.
• Role split: the main Session only routes (forwards the original Trigger +
  routing facts, no technical decisions, routing note ≤30 words, one routing
  call batches up to 20 decisions); Executors read original sources, judge
  scope, implement and verify. The main Session never waits — a host guard
  refuses sleep, shell timeouts >30s, and job waits >5s.
• Chat messages: one sentence by default, hard limit 100 words; main-Session
  coordination notes to a Ticket ≤100 words and grant no authority.

Architecture (007-architecture)

• One Engine is the only writer of Triggers/Threads/Decisions/Tickets/
  Assignments; every command mutates its aggregates in one transaction; ports
  enqueue external work inside the transaction and adapters perform it after
  commit (afterCommit). Callers get only their role's Pick of the Engine
  (Sources / Main Session / People / Settings / Executor).
• Effects: a durable side-effect queue (kind/key rows; re-enqueueing a waiting
  key replaces its payload without changing queue order); per-kind handlers
  with their own concurrency and backoff; throwing Later defers without
  counting a failure.
• Decisions record structured reasons: a code + values (+ per-Trigger id),
  rendered to text for agents and panel from one code table.
• Persistence: one SQLite file; domain tables per aggregate plus a
  disposition table, an effect table, an outbox receipt table (a message
  id is never queued twice; dropped messages keep when/why), and typed KV.
  Generated columns (open, active, subscribed) index exactly the working
  set a pass must read. Schema version only increases; nothing deletes old
  records yet (named as a known unbounded-growth gap).
• Reasons, stages, and health have single definitions used by core, panel and
  prompts alike ("one writer per state", "one place per concept").

2. Concept-by-concept mapping to our system

Legend: have = we do this today in substance · partial = shape exists,
weaker or by convention only · lack = no equivalent.

A. Intake, authorization, work acceptance

B. Queue data model (code#3424 / #3418 territory)

C. Execution, sessions, routing (lanes + conductor + router; opencode#1014)

D. Surfacing: panel vs chat escalation + morning readout

E. Prompts / instructions

3. Most adoptable ideas (ranked by value ÷ cost)

Each idea names its source doc, every plausible home, and a one-line cost note.

3.1 Structured question field on the work item ("Attention")

Their Executor asks through a structured field on its Report; the question
travels with the Ticket and the person's answer returns to the same Ticket
(001-domain glossary; 003-execution; 004-prompts "Ask through human_action").
Ours: escalations are chat prose + user/escalated labels; the substance rule
(what/options/recommendation/why) is enforced socially.
Homes: code#3424 (notes schema gains an attention note type with
question/options/recommendation/answer fields — fits the typed-notes piece
directly) · lane instructions (repo-queue-worker-instruction.md,
lane-shift-instruction.md: escalation = write the attention note, then the
chat line renders it) · escalation discipline / morning readout (readout
lists open attention notes instead of re-deriving them).
Cost: small — one note type + fields in a design already in flight; readout
generation is a follow-up, not a prerequisite.

3.2 Accept mode per producer: off / observe / auto

Inferred work starts in observe: positive assessments recorded as
"would accept", nothing starts; flip to auto after reviewing the recorded
Decisions (002-authorization). We ran observe once, system-wide, by hand
(pilot shadow); every new producer since went straight to auto.
Homes: code#3424 (a mode column on producer/queue config is schema-shaped)
· producer job bodies (new-issue-creator, pr-diff-review, pr-comment-review:
new filing rules/kinds start in observe for N runs) · fleet monitor (reports
would-accept counts so the flip decision has data).
Cost: small–medium — a config flag + producers honouring it; the win is a
safe on-ramp for every future producer rule change.

3.3 Derived "waiting-on" stage instead of (only) a stored status

Stage computed from facts by a precedence table — undelivered → person/answer →
person/review → person/blocked-failed → queued → idle → working — and the label
names whom it waits for (003-execution stage table; 005-panel principle 2).
Homes: code#3424 (add a derived waiting-class to the design: inputs are
status + blocker links + park kind + last note type; stored status_reason
stays as the human gloss) · code#3418 (capacity-wait vs external-wait is
exactly two rows of this table — fold them in rather than inventing parallel
vocabulary) · fleet monitor + morning readout (queue health reported in
waiting-on classes; "31 parked" becomes "12 on CI, 9 on review, 4 on Drew,
6 capacity").
Cost: small in the design phase (a view/function over #3424's tables);
medium if retrofitted after implementation — decide it inside #3424 now.

3.4 Decision/reason codes as a shared vocabulary

Decisions and transitions record a code + values from one table; agents,
panel and humans all render from the same codes (007-architecture Model;
001-domain disposition). Our reasons are free text (last_error, progress
blobs) — the failure #3424 exists to fix.
Homes: code#3424 (notes/events carry reason_code beside the free-text
body; seed the code list from our real vocabulary: ci_wait, codex_review,
quota_reset, capacity, blocked_on_task, drew_decision, upstream_pr, …) ·
lane instructions (terminal verbs require a code) · repo-queue.py (validate
codes at the verb, like packet schemas).
Cost: small — a controlled vocabulary list + one column; discipline cost
only if lanes must retrofit old rows (don't — codes apply going forward).

3.5 Follow-up ownership + hand-back, applied to PR shepherding

A follow-up on a work item's own thread is owned by that item's worker, which
either handles it in-scope or hands it back once with a reason; only unowned
messages become new intake (002-authorization; 003-execution). Our analog:
review comments and CI results on a PR with a live shepherd task should route
to that task (as a resume trigger with context), and a shepherd that judges a
comment out-of-scope hands it back as a new triage packet naming why — instead
of today's pattern where pr-comment-review files fresh issues that can collide
with the shepherd's own work.
Homes: lane instructions (shepherd resume protocol) · pr-comment-review
job body (check for a live shepherd/pr task before filing) · code#3424
(hand-back = a link + note with provenance inferred, reason code from 3.4).
Cost: medium — mostly instruction + one producer check; no schema beyond
what #3424 already plans.

3.6 Reserved human-priority capacity in claiming

Worker slots reserve +1 beyond the limit for a person's message or a status
request, and human wakes preempt new launches (003-execution Concurrency).
Our failure shape (2026-11-01): Drew-prioritized work waits behind whatever
the shift already claimed; there is no mechanism for a Drew directive to
preempt inside the queue system.
Homes: code#3418 (claim-side companion: expedite/Drew-originated tasks may
claim against a reserved budget slice — e.g. a lane may exceed its bundle cap
by one for a priority-90 task, or one lane slot per queue is reserved for
expedite until T-30 of the shift) · lane instructions (the reservation rule
lanes can actually execute) · conductor instruction (dispatch gate honours the
reservation when seating sessions).
Cost: small — a claim rule + instruction text; no schema beyond #3418's
required_budget_minutes conversation.

3.7 Stored-work discipline for side effects (mini-outbox)

Side effects are stored in the same transaction as the state change and
executed after commit with per-kind backoff; a kind surfaces as a system
problem only after 3 consecutive failures of one item (003-execution "Stored
work"; 007-architecture Effects). Our lanes post GitHub comments / enqueue
follow-ups / fire signals inline; a crash between the DB verb and the comment
is exactly the claim-evaporation class we repaired on 2026-10-26.
Homes: code#3424 (events table already stores the intent; add an
effects/outbox table for comment-mirroring — note piece 4 already promises
"the system comments notes back automatically", which is an outbox consumer)
· repo-queue.py (verbs enqueue effects; a small drainer in the fleet monitor
or a hook executes them) · fleet monitor (per-kind failure accounting replaces
ad-hoc divergence repair).
Cost: medium — one table + a drainer; but it mechanizes repairs the fleet
monitor currently does by hand every hour.

3.8 Generated working-set columns for queue reads

Their store computes open / active / subscribed as generated columns
with partial indexes so a pass reads only active work (007-architecture
Persistence). Our claim/health queries filter the full tasks table by status
and timestamps on every lane cycle.
Homes: code#3424 (schema design: generated columns or partial indexes for
claimable-now, parked-due, blocked-on-open-task working sets — pairs with the
normal-form ruling already recorded) · supabase migrations chain (lands as
part of the #3424 implementation migrations).
Cost: small — index design inside migrations already being written.

3.9 Prompt-precedence ladder + volatile-state-last, written into fleet instructions

One explicit ladder (host-enforced facts > standing rules > matched task
requirements > instruction text > repo/issue text as data), and prompts
assembled stable-first with volatile state (quota snapshot, gate state) last
(004-prompts). Our lanes already behave this way; writing it down once ends
per-instruction-file reinvention and gives the injection rule a citation.
Homes: lane-shift-instruction.md + repo-queue-worker-instruction.md
(one shared preamble section) · conductor instruction (same preamble) ·
opencode route/session prompts where the router assembles per-session context
(adjacent to #1014's surfaces, not inside its scope).
Cost: small — an editing pass over instruction files we control.

3.10 "Few concepts" audit of our own surface

Their design refuses new concepts: a business need becomes an attribute of an
existing concept or prompt text (000-philosophy; 001-domain rejected-concepts
table is the worked example). Our surface has grown by accretion: 400+ labels,
multiple overlapping job types, per-queue instruction variants.
Homes: goal-level review (label taxonomy file
files/label-taxonomy-2026-10-25.md — prune labels no query uses) ·
stewardship cycle (a standing "concept count" check when a new job/instruction
is proposed: attribute of an existing thing, or genuinely new?) · code#3424
(the design already applies this to links/notes — extend the same test to the
pieces' own vocabulary before implementation packets split).
Cost: small per pass, recurring; the cost of not doing it is the drift
that made tonight's routing incident hard to reason about.

4. What they do that we deliberately do differently — and should keep

1. Merge authority. Their default: the agent account never enables
   auto-merge, people merge, policy lives in a "Delivery requirements" prompt
   (003-execution). Ours (Drew, 2026-10-24/25, restated since): Muse merges
   verified finished work itself — "if an issue or PR says it needs a human,
   they mean you" — drafts and conflicted PRs included, fix forward. Keep
   ours. It is the throughput decision the whole fleet is built on; their
   model optimizes for a team of human colleagues whose attention and trust
   are the scarce resource, ours for a single operator who has explicitly
   delegated the merge call. (Borrow only their attribution awareness:
   merges are attributable actions, which our provenance piece 6 now records.)

2. Start narrow / observe-first as the permanent posture. Their
   responsibility section: begin with a short allowed list and record-only
   proactive work; widen only when the record looks right; never produce
   volume (000-philosophy). We already passed that gate deliberately (pilot
   shadow → Drew-approved cutovers, Phase 3 approved 2026-10-26) and Drew's
   standing direction is the opposite failure-mode guard: "fix it means fix
   it now", file the issue in the same pass, merge when verified. Keep our
   posture; adopt observe-mode only as a per-producer on-ramp (3.2), not as a
   fleet-wide temperament.

3. One work item per session, session per item. Their Executor model is
   one Session + directory per Ticket, resumed across days by subscription
   fan-out (001/003). Our lanes are fresh-context cron shifts claiming bundles
   — chosen 2026-10-26 precisely because long-lived worker contexts compact
   and die mid-bundle ("cron jobs don't compact"). Keep the shift model. Our
   continuity lives in the queue + GitHub + handoff snapshots, not in a
   session's memory — which is also why design(queue): durable task data model — blocker links, park revalidation, status reasons + notes, full event history, actor provenance #3424's notes/events matter more for
   us than their Session-history mechanics would.

4. Panel as a separate UI artifact. Their panel is a standing view inside
   the DeepSeek Harness (005-panel). Our surface is chat + GitHub + the
   morning readout, and Drew works from his phone. Keep the surface; adopt
   the panel's principles (needs-me-first ordering, waiting-on labels,
   actionable-only problems, counts that equal their lists) as readout
   requirements — 3.1/3.3 are what make them generatable from data instead of
   assembled by hand.

5. Waiting belongs to Sources; no park timers in the core. They reject
   delayed-Trigger scheduling inside Eval: a condition that needs waiting is
   a Source that checks again itself (001-domain rejected concepts). Our
   park/not_before + scheduled revalidation (design(queue): durable task data model — blocker links, park revalidation, status reasons + notes, full event history, actor provenance #3424 piece 3) puts waiting
   inside the queue deliberately — because our "sources" are cron jobs and
   GitHub state, and a park with a known external instant (quota reset, CI
   completion) is more honest as data than as a poller. Keep ours; design(queue): budget-aware claiming — parks carry a minimum required time budget, claim matches the claimer's remaining shift budget #3418's
   external-wait vs capacity-wait split already encodes the part of their
   objection that was right (a capacity wait is not a time wait).

6. GitHub as the canonical work surface. Their Sources translate GitHub
   into an internal domain and the Ticket state lives in their store
   (001-domain "What is reusable"). Ours keeps GitHub issues/PRs canonical —
   the queue is a control plane, the discussion and the audit trail people
   read live on the issue — and design(queue): durable task data model — blocker links, park revalidation, status reasons + notes, full event history, actor provenance #3424 piece 4 mirrors notes out to GitHub
   for exactly this reason. Keep ours; it's why a person can audit any fleet
   action from the repo alone.

7. Escalation content. Their questions are one concrete question, short
   (000/004). Drew's rule requires the substance in the message itself —
   what, options, ramifications, recommendation — because he rules from the
   chat, not from a panel. Keep ours; 3.1 adds their plumbing (the question
   as structured data on the item) underneath our content rule, not instead
   of it.

Prepared for the repo-health fleet's design work (code#3424, code#3418,
opencode#1014, fleet instruction files). Reference only — no GitHub posts made.