Tempo
The whole thing, on one page
A person picks a feature off a ranked list. AI agents research it, build it, and test it, and nothing they claim is taken on their word: separate agents that never saw the work check it before any person is asked to look. The person watches working software, says what to change, and lets it run again until it's right. Engineering reviews it and merges it. That's the build loop (Nightshift). Dispatch is the thin layer that lets ten people do this at once. It does three things. It keeps one ranked list of what to build. It gets each question that comes from outside a build to the one person who can answer it, and puts the answer back into the work the same day; that is the hard half, and where a layer above the loop earns its keep. And it watches for the few cases where two branches really collide: a shared contract, a generated file, a database change, a component everything imports.
It runs on ClickUp, git, and one recorded 30-minute meeting a week that already exists. Nothing new to install for the people deciding and reviewing; an operator installs one package (page 13). Phase one is just the list, the weekly half hour, and one scheduled job; everything else on these pages arrives only if the pilot works and the group grows.
Two things the diagram cannot show. A cycle is cheap (hours, not a sprint), so nobody expects the first pass to be the final product: you look at what it built, say what you want different, and it comes back rebuilt and re-tested the same day; the same is true when a reviewer sends feedback. And the loop is a floor, not a mold: the checks are fixed, the craft in the middle belongs to whoever is building. Both on the Fast loops page.
The operator's part, in four lines
- Claim a ticket from the list.
- Run the loop on it, as many rounds as the work needs.
- Watch the demo, say go. The pull request opens itself.
- Answer when asked. You are only ever asked about decisions.
Two things, working together
The way of working
A handful of checkpoints every build passes (real tests, an independent check of the work, a demo of working software), a ticket anyone can see, three moments where a person decides, and one named owner for each kind of question. This is the part that stays consistent from builder to builder, because it is what makes anyone's work trustworthy to everyone else. It was distilled, not accumulated: if a rule didn't have to be shared, it didn't make the list.
The tools that make it easy
A build-loop package an operator installs once, and one scheduled job that keeps the list and the checks current. They do the monotonous parts (the ticket upkeep, the test runs, the environments, the review paperwork) so following the way of working costs nothing. You could follow it with no tools at all; the tools just make it cheap.
The three names from the start page, mapped to the steps: Nightshift is the AI loop (step 3; in depth from page 11). Dispatch is the software (steps 2 and 5, plus building the weekly agenda and the small shared-piece check; it never posts to anyone on its own and never merges). Daybreak is the weekly meeting (step 4, the first half hour of Sana Mondays).
Where this came from
- The multi-team doc already designs the engineering side: lane teams, a platform boundary, a worktree per team, gates as CI. In plain terms: each area of the product has its own team and reviewer, shared code has one owner, and the repo's checks run automatically. Dispatch sits on top of that and contradicts none of it (page 1, written for that doc's author).
- Your go-to-market workplan is already the list: 113 capabilities with honest states about what is built, partial, or missing. Dispatch adds rules around that existing list rather than creating a second one (page 6, page 7).
- The first Sana Monday put the question on the record: how do several of us work on Sana at once. As you pointed out, branches on different features rarely collide; the real cost is a decision that waits on a meeting. Pages 2 to 5 are built around that, and the collision check is one small row on page 5.
Everything in here is a proposal. The open questions and a first step that costs one hour are under the ask.
The idea
What it solves, for you
Read the part written for you. If it doesn't sound like your week, this proposal has missed, and I want to know.
If you own the architecture
You wrote the rules into the codebase so you wouldn't have to repeat them in every review. This runs every build through those rules, every time, before anyone asks for your eyes. What reaches you is only what is genuinely yours: a real either-or about the architecture, a question of who owns a shared piece of the codebase, a redesign worth arguing about, arriving batched and pre-read with a recommendation attached. Review stays yours; the policing you shouldn't have to do is done before the PR opens. Nothing merges around you, and nothing sits waiting on you that someone else could have answered.
If you're an engineer
Your way of building stays yours. The loop does not tell you how to design or which tools to use. It takes the parts you'd rather not do (keeping the ticket current, running the whole test matrix in the right order, standing up environments, packaging the thing for review) and it guarantees that any code you're asked to review already passed the repo's own checks and tests before you were asked. When you review someone's work and send feedback, it comes back folded in and re-verified in hours, not next sprint. And when you build, nobody else is quietly editing the file you're in: the few real conflicts (a shared piece of code, a change to how data is stored) get flagged early and landed first. It's a starting template: some people run it unchanged for a cycle to see what the checks catch, then bend it to their own tools and habits; you may not need even that. The few pieces that stay fixed are the ones that make your work trustworthy to people who didn't watch you do it.
If you're a product manager
For work that raises no architecture question, you can take a feature from "named in Slack" to a merged pull request, pulling an engineer in only for the review; when an architecture question does come up, it goes to its owner as a single question, not a handoff of the work. The loop does the research, the build, and the testing to the same bar as any other build; you make the product calls, watch the demo, click through the working software, and say go. It is deliberately good enough that the simpler features don't need a deep engineer to run them. This is not hypothetical: the first feature shipped this way was merged this weekend, with the engineering review folded in.
And for the team
One list everyone trusts. Decisions that take a half hour a week instead of a meeting per question. A record of every decision with its reasons, written the day it was made. And a quality bar that is the same no matter who, or what, wrote the code.
The idea
Fast loops, not big bangs
Nobody expects the first pass to be the final product. The whole system is built the other way around: make one cycle cheap enough that you can afford as many as the work needs.
Here is what all the automation and checking is actually for. Not "no humans": iteration fast enough that a human's feedback lands the same day it's given. You look at working software, say what you want different, and go do something else while it comes back rebuilt and re-verified. The reviewer does the same at review time; their feedback goes back into the loop and returns already re-checked. The real feature that shipped this weekend took two full build cycles, plus a review round where engineering feedback was folded in; every lap was hours, not days.
A floor, not a mold
The second thing to hold onto: Nightshift sets a quality floor, it does not pour a mold. The fixed part is deliberately small, and it was distilled, not accumulated: only what has to be consistent from one builder to the next made the list. The ticket stays current. Every build passes the same testing and verification before a human is asked to look at it. The human touchpoints happen. That's the whole floor, and it is the same for everyone.
Everything in the middle (how a thing is designed, architected, and built) belongs to whoever is building it. A product manager who doesn't write code can lean on the defaults end to end, and the floor makes that safe. A senior engineer working one of the hard areas can run their own tools, their own habits, and their own architecture through the same checkpoints, and the floor makes that trustworthy to everyone else. The loop also scales to the size of the work: a five-line follow-up runs the same loop scaled down; a big redesign gets the fuller path with a design conversation first. The point was never to prescribe how software gets created. It is to make the quality floor automatic, so the creative part is where the time goes.
The mechanics · 1
How it fits your multi-team plan
Your multi-team doc settles who owns which code, how a lane boots, how schema changes serialize, and that gates become CI. Dispatch takes those as given and adds the part the doc leaves as open threads: which work gets done, by whom, in what order, and how decisions reach the people building.
This page maps that doc section by section and is written for its author. If you have not read it, skim the last paragraph and move on; nothing later depends on this page.
| Your section | What it settles | What Dispatch adds or relies on |
|---|---|---|
| §1 Lane teams, per-lane personas, per-lane launch docs, lane-scoped routing | How a lane boots and what its agents reflexively check | Each operator boots their lane's loop with that lane's launch doc and persona. The Board's Lane field routes tickets and reviewers to the lane. |
| §1.3 open threads: roster shape per lane · cross-lane escalation · orchestrator personas | Cross-lane escalation becomes a ticket to the owning lane or platform, never a reach into another worktree. Roster shape per lane stays yours. | |
| §2 Platform boundary: platform owns the substrate, lanes own verticals, seams are platform-adjudicated | Who may edit what | The first claiming check reads your map: platform-owned code is not claimable by a lane operator; the need becomes a ticket in the platform lane. Dispatch itself sits alongside the platform team, not inside it, and owns no code. |
| §2.5 Convention hygiene is an active platform job | The weekly Pulse reports conventions that keep tripping builders into the platform backlog. | |
| §2.6 open threads: lane roster · agent lane · config surfaces · platform team size | A lane roster proposal (the 13 GTM buckets collapsed to your §2.3 cut) goes to the Bet for you to ratify. The rest stays yours. | |
| §3 Schema and migrations: dual track, reconciliation gate, the freeze moment | How schema changes serialize | Schema-touching tickets carry a schema tag; Dispatch allows one in flight per lane; your migrations-equal-declarative check is a named, required CI stage in the merge lane, enforced on every PR rather than only written down. |
| Cross-cutting: worktree per team · gates become CI · structural invariants | The review class, and the narrow collision class | Gates-as-CI is the merge lane. Your cross-model review (Codex builds, Claude reviews) is the CI review stage, with a failure contract: disagreement blocks merge until the named reviewer picks. The collision check is limited to what you named: shared contracts, generated files, schema changes, widely imported components. Everything else merges mechanically. |
| Status / next: ratify 1 → 4 | Dispatch's first phase is your steps 1 (lane roster + platform boundary) and 4 (CI gates) plus the operating rules. Steps 2 and 3 stay yours. |
Two of your principles run through everything here. Structure over discipline: shared pieces land first, branches stay short, and the check that flags a shared contract or a schema change reads git, not anyone's comments. Persona shapes reasoning, gates guarantee correctness: the Fast track ships with no design review because its acceptance bar is parity with the legacy product, proven by tests, a demo, and a front-desk check, not by anyone's opinion.
dispatch: pause) by the Dispatcher or the platform owner; claiming and merging then continue by hand exactly as today, and nothing waits on Dispatch to come back. If the checks are wrong, they get fixed in the open, not routed around.The mechanics · 2
A ticket's life, end to end
Who touches it, in what order, and how long each step takes. Left to right is time.
Fast-track example: Refunds workflow
A GTM row that is Partial and a pilot blocker, in the Billing lane. One operator, one Monday. (Track says how close to the old product the work stays; Weight says how much design judgment it needs; Lane is the area of the product.)
- the Bet's three deciders; the Dispatcher drivingThe Bet, 1h, quarterlyRow ranked (pilot blocker; unblocks statements and ledger polish). Track = parity port, Weight = Light, Lane = Billing. Status
ready for development. - operatorMon 9:00Assigns herself and moves the ticket to
in development. Dispatch reads the branch from git and checks she is not waiting on an open decision, WIP (1 of 2), and whether the ticket touches a shared piece (a contract, a generated file, the schema, a widely imported component): clear. One line to the channel: who, what, which lane. (Phase one: the operator posts the claim too, because the check runs on a schedule until the webhooks are live.) - Nightshift~30 minLegacy behavior (void vs refund in ChiroHD), current-state screenshots, and a parity checklist written onto the ticket as acceptance criteria. The front-desk reality check gets the checklist with one question: does matching ChiroHD here preserve a workaround the front desk hates? Two-business-day clock; the build proceeds meanwhile.
- Nightshift~20 minPlan, then a fresh agent challenges the plan.
- Nightshift~2–3hBuild (Codex), then the verification chain (Claude): fresh gate review → fix → fresh re-verify → all clear. The repo's CI checks run in order;
mainchecked too. - Nightshift~30 minDemo video, ticket acceptance criteria ticked, PR description, review request. A fresh reader checks every artifact against its checklist before a human sees it.
- operator5 minWatches the demo, runs the five-minute click path, says go.
- Dispatch15 minOpens the draft PR, moves the ticket to
in review (pr created), assigns the Billing lane's named reviewer, adds watchers, drafts the nudge for the operator to send. - the lane's reviewer≤2 business daysApproves, or sets one of two labels.
fix round: the change stays inside the files already in the PR and no product decision moves.redesign: the outcome or a decision changes. Fix rounds run on the same branch without the operator and come back re-verified, usually the same day; iterating here is normal, not a failure. Redesign goes back to a write-up. Dispatch reads the label; it never guesses. - CI, then the lane reviewer or the platform ownermerge laneRebase, green, merged in order.
pr merged. The GTM row flips Partial → Built and the Pulse counts it.
Claimed Monday morning, PR ready by mid-afternoon, merged within two business days. Operator touches: claim, the demo check, sending the nudge, and the merge go.
The Deliberate-track variant: Treatment plan
Partial, needs a spec, pilot blocker. At the Bet it is Track = redesign, Weight = Heavy, status in design. Nightshift runs discovery and produces a short write-up for review: a one-page problem statement, three options with one recommended and sized, a clickable prototype, numbered questions each with a recommended answer, and the PRD's contract layer drafted in Dr. C's house template. The write-up goes to the async lane first, routed by question type: product intent to the product decider, the data model to the lane reviewer, anything architecture-adjacent to the platform owner. What stalls, or genuinely needs a conversation, lands on the next Daybreak agenda with only the people that item needs. The decision is captured from the recording, written to the ticket and the decision record, and the build proceeds on the chosen option. From there it is the Fast-track sequence, with the product decider on the demo review.
The cadence rule: a meeting's cadence sets a hard floor on decision latency; by arithmetic, a weekly-only forum means a multi-day median. The async lane is the engine and Daybreak the backstop, and the Pulse tracks the share of decisions resolved async: if the meeting is making most of them, the lane is broken.
The mechanics · 3
The humans: who decides what, and when
Two moments, one of which exists already. Everything else is async and pre-read, and each question goes to exactly one owner, so nobody gets pulled in ten directions.
The Bet · quarterly, one hour
Three deciders (platform owner, product decider, engineering lead), the Dispatcher driving. Input: a ranked gap list with evidence per row (page 7 is the first run). The room does three things only: veto rows that shouldn't be built, re-rank, and settle Track where the list hedges. Output: tickets on the Board with Track, Weight, Lane, and blocker tag set. Re-run when ten or more rows change order.
Daybreak · weekly, 30 minutes
Proposed as the opening of Sana Mondays. The agenda builds itself 24 hours ahead from every decision that stalled in the async lane, ranked by how many tickets each one unblocks, then blocker tag, then age. Each item carries its write-up or demo, the question, the recommended answer, and the people it needs. People join for their items and leave. Decide or defer; a deferral records what would settle it. Recorded.
The async lane comes first
Most decisions never reach the room. A question becomes an assigned comment on the ticket to the one person who owns it, with a recommended answer and a two-business-day clock. Reversible work proceeds on the recommendation meanwhile; only forks with expensive reversal (a new data model, patient-facing behavior, anything against canon) wait. Daybreak takes what stalled or what genuinely needs a conversation.
Who gets which question (Dispatch enforces this by lane and question type)
| Question type | Owner | Trigger |
|---|---|---|
| Product intent, UX pattern, "should Sana do this" | Product decider | Every Deliberate-track write-up; every Fast-track ticket the operator marks Deliberate |
| Architecture, platform boundary, anything that touches the substrate or canon | Platform owner | Only when the write-up's data-model or platform question is flagged, or the ticket is in the platform lane. The default is that the platform owner is not asked. |
| Technical approach, feasibility, the merge | Lane reviewer (one named engineer per lane) | Every PR in the lane; technical questions in write-ups |
| Does matching ChiroHD here preserve a workaround the front desk hates? | Front-desk reality check | Standing check on every Fast-track parity checklist and every write-up that touches front-desk or clinical workflow. Ten minutes, async, two-business-day clock; the build proceeds meanwhile on Fast track and waits on Deliberate. If the check lands after a Fast-track merge, it opens a follow-on ticket in the same lane at the top of the lane's order; it never reverts a merge. The Pulse counts late catches, and where they keep happening the clock shortens or the lane moves to Deliberate. |
| Compliance, PHI, patient-facing content | The HIPAA gate first, then the Dispatcher | A human reviewer only on escalation |
The roles to fill (the kind of person; who fills them is Gabe's call)
| Role | Does | When · load | The kind of person |
|---|---|---|---|
| Dispatcher | Owns the Board and the sweep; drives the Bet and Daybreak; carries urgent asks between them; publishes the Pulse; owns no code | Weekly · the coordination that used to be everyone's | Product-operations minded, comfortable in ClickUp and git, has run the loop end to end at least once. Sits alongside the platform team, not inside it |
| Platform owner | Ratifies the Bet; architecture and platform-boundary decisions; owns the lane roster and the substrate per the multi-team doc | Bet quarterly; Daybreak only for own items; ~1h/week | The architect who owns the shared substrate and the lane roster |
| Product decider | Product-intent decisions on Deliberate items; edits and approves the PRD contract layer; demo review on Heavy features | Async first; Daybreak only for what stalls; ≤30 min/week, pre-read | Owns the product direction; can say no to a redesign |
| Engineering lead | The engineering half of the Bet; the merge lane's rules; names the lane reviewers | Bet quarterly; async otherwise; ~1h/week | Senior engineer with cross-lane view |
| Lane reviewer (one per lane) | Reviews every PR in the lane; sets fix round or redesign; answers technical questions in write-ups | Async, ≤2 business days per PR | An engineer with depth in that area of the product |
| Front-desk reality check | Reads every Fast-track parity checklist and every workflow write-up for one thing: does matching ChiroHD preserve a workaround staff hate? | Async, two-day clock; ~10 min per ticket | Someone who has trained or sat with front-desk staff and knows their workarounds firsthand |
| Operators | Claim, run the loop, say go on the demo, send the nudge | Continuous; 3–4 touches per Fast ticket | Anyone who can run an AI build loop: engineers with their own harness, PMs running Nightshift |
Names are deliberately absent. The roles are the proposal; assigning them is the first thing the Bet can do, and the Dispatcher can bring a suggested slate to that conversation if that helps.
The mechanics · 4
The operator: Nightshift on one page
An operator is anyone on the team running the loop: an engineer with their own setup, a PM, or a product-side teammate who knows the software from the user's seat and runs the loop's defaults. Dispatch treats them all the same, because it reads git and the Board, not your tools.
Four lines
- Claim a ticket from the Board: assign yourself, move it to
in development. Name the branch for the ticket; the rest is read from git. - Run Nightshift on it, or your own loop.
- Watch the demo, click through, say go. The PR opens itself.
- Answer Dispatch when it asks. It only asks about decisions.
What Nightshift does for you (the full mechanics are on page 12; the package on page 13)
Intake writes the ticket as a user story. Discovery runs several independent research passes (legacy code, current-state screenshots from a standing sandbox, the reference canon, Sana's own code, demand evidence) and reconciles them. A plan is written, then a fresh agent challenges it. The build runs on a short-lived feature branch off main. Then the verification chain: a fresh-context gate review, a fix round, a fresh re-verify, repeated until all clear, with the reviewer never from the builder's model family. The repo's CI checks run before any PR opens. A demo video is cut at human speed and checked by a fresh reader. The ticket, PR description, and review request are written against fixed checklists. Then the one human gate: watch the demo, click through, say go.
Fast track parity port
The bar: works as well as ChiroHD or SKED did, or better. Acceptance criteria are generated from what the legacy product actually does, as a parity checklist, plus Sana's invariants, plus Ellen's check that parity isn't preserving a workaround. No design review. Humans at the demo check and the merge.
Deliberate track enhance · redesign
Adds a short write-up before build (problem one-pager, options, prototype, questions), the async lane, and Daybreak when needed; the PRD's contract layer at spec; the right owner routed by question type. Slower on purpose. If a Fast ticket turns out to hide a product call, the operator marks it Deliberate and the write-up goes up; it never moves back mid-flight.
If you run your own harness
Nothing changes. Name the branch for the ticket (sana-14/refunds-workflow) and Dispatch links branch to ticket by that prefix; the PR title carries the ticket link. Forget, and Dispatch asks once. From there it reads your branch and its changed files from git and the PR, so the shared-piece check works whatever produced the code. Your gates and CI still run. The one thing every operator does the same way is the ticket: claim it, keep it in the right status, and answer the questions Dispatch puts on it.
Measured, not modeled
The first side-by-side run of Nightshift (the check-in feature, 8/28) built the same feature twice and reached independently verified all-clear on both builds. The Codex build took about two hours from plan to verified and cost roughly $30–60; the Claude build took a little over six hours and roughly $450–500 including its review rounds. Both builds independently created the same class of kiosk authorization hole, and only fresh review caught it, which is the strongest argument in this document for the verification chain and for cross-model review.
The mechanics · 5
What runs itself
Dispatch is software: an orchestrator that reads the Board, git, and the channel, and writes back to the Board and the channel. It posts records to the shared channel and the ticket; it never sends anything to a person directly, and it never sends what a human is meant to send. It never merges. And the status moves that mean a human decided something (a design approved, a merge authorized) only ever happen from that human's action.
| Trigger | Dispatch does |
|---|---|
Ticket → in development | Dependency and WIP checks; a look at whether the ticket touches a shared piece (a contract, a generated file, the schema, a widely imported component), read from git; one-line broadcast to the channel |
| A branch's changed files grow | Re-check for shared pieces only. If two branches touch one, both operators get a comment naming it, and the shared piece is split out and landed first. Two branches on different features touching different files are left alone; git merges them |
| Demo check "go" | Draft PR, status, attachments, the lane's named reviewer assigned, watchers, nudge drafted, watch registered |
Ticket → in design with a question, or marked Deliberate mid-flight | Async-lane clock starts with the owner set by question type; the item becomes a Daybreak candidate only if it stalls |
| 24h before Daybreak | Agenda built and ranked; write-ups attached; owners named per item; pre-read posted |
| Recording lands | Decisions extracted against the agenda's ticket ids; written to the ticket (with rationale and alternatives), to the decision record, and to the reference repo if canon-grade; every running loop that depends on them is re-briefed; a confirmation posts with a 24-hour correction window; anything ambiguous becomes a question to the decision owner, never a guess |
Reviewer sets fix round or redesign | Fix round (the change stays inside the PR's files, no decision moves) runs on the same branch and re-verifies; redesign (the outcome or a decision changes) goes back to a write-up. Dispatch reads the label; it never infers severity |
Deliberate branch falls more than a week behind main | Flags it to the operator; rebase is the operator's, not Dispatch's |
| A claimed ticket has no commits for ten business days | Asks the operator once; silent for two more days, the ticket returns to the Board and the branch is kept as reference. Nobody's work is deleted; the ticket just becomes claimable again |
Anyone comments override: reason | The check is skipped for that ticket, the override is logged, and the Pulse shows it |
| PR merged | pr merged; the GTM state flips; the Pulse updates |
| Weekly | The Pulse |
The collision half, kept small
Two people on separate branches doing different features almost never collide; version control merges them. The cases that bite are narrow and predictable, and they are handled by landing the shared piece first and keeping branches short, not by dividing people across the product.
- Short-lived branches off
main. Rebase before ready. A branch more than a week behind gets flagged (page 5's table). - Shared pieces land first. A schema change, a generated file, a shared contract, or a component everything imports gets its own small PR, reviewed by the platform owner, and the feature branches rebase onto it. Platform-owned substrate is never changed inside a feature branch.
- Dependencies. A ticket whose "waiting on" tickets are open cannot be claimed, and the Board says what it waits for.
- WIP. One Deliberate ticket in flight per operator; up to two Fast.
- Merge order. PRs merge in the order they go green; a red on
maingets its own cleanup PR first; the migrations-equal-declarative check is a required stage.
The mechanics
ClickUp supplies the triggers (Automations and Autopilot Agents fire on status changes, assignments, and comments; webhooks carry them out) and the durable surfaces (tasks, dependencies, assigned comments, Docs, dashboards). The reading and writing live in the Dispatch orchestrator; every judgment stays with a person. Phase one runs it on a schedule; phase two wires the webhooks. The decision pipeline takes a meeting transcript in and writes decision records out, deliberately independent of which recording tool made the transcript.
The mechanics · 6
The Board
One list in the Sana Platform space, seeded from your GTM conversion: one task per capability. Your seven statuses, unchanged. Personal lists become "assigned to me" views on it, so there is exactly one place a ticket can live.
| Field | Values | Where it comes from |
|---|---|---|
| Status | backlog · in design · ready for development · in development · in review (pr created) · pr merged · cancelled | Ryan's List, as is |
| Track | Parity port · Port + enhancement · Redesign | The three buckets from the first Sana Monday; sets the default Nightshift class |
| Weight | Light · Heavy | Scored at intake on five criteria (net-new surface, architecture fork, ambiguous intent, cross-module ripple, research could change the design); re-scored at discovery exit |
| Lane | The 13 GTM buckets, collapsed to your lane roster | GTM workplan; your §2.3 |
| State | Built · Partial · Spec'd · Missing | GTM workplan, kept live by merges |
| Blocker | Pilot blocker · Demo gap · Post-launch | GTM workplan |
| Unblocks | count | ClickUp dependencies |
| Operator · Branch · PR · Demo | links | Claiming (branch from git) and the review request |
The Releases list stays as it is. "One ticket per unit of work, treated like Jira" holds exactly as you set it.
Where the rows come from
The GTM workplan's 113 rows are the seed: 48 built, 38 partial, 13 spec'd, 14 missing at r4. A gap-discovery sweep refreshes the list from four inputs (the workplan, the capability matrix, the parity notes per domain, and the Intercom customer-asks corpus) and proposes, per row, the state and its evidence, the demand signal, dependencies from the code, a Track and Weight with the reason, and how many other rows it unblocks. Page 7 is the first run of that sweep, ranked, with every score broken out so it can be argued with. That ranked draft is what the Bet validates.
The mechanics · 7
The list, ranked: what the Bet would see
The first run of the gap-discovery sweep on the four inputs (the GTM workplan, the capability matrix, the parity notes, and the customer asks from the support inbox). 65 gaps from the workplan once the 48 Built rows are set aside, plus 6 the workplan does not list, plus 7 decisions that unblock more than any build. Every score is broken out; change the weights and the ranking re-sorts. Star rows to build a shortlist; export what you land on.
The seven decisions that unblock the most
| # | Decision | Unblocks | Where it lives today | Route |
|---|---|---|---|---|
| 1 | Canonical permission model (two competing designs, neither built) | Staff management, the report engine's field-level permissions, audit-viewer access rules | Ryan's List, in design | Daybreak, first item: Gabe + Ryan |
| 2 | PDF renderer: Typst (pure Rust) vs headless Chromium | Statements, CMS-1500 at scale, financial report PDFs | Ryan's 8/24 Slack question to Gabe | Async lane, Gabe |
| 3 | Pilot profile: new offices, or offices migrating from ChiroHD? | Whether bulk import and migration move from post-launch to pilot blocker | Not on the record | The Bet: Gabe + Dr. C |
| 4 | Fee-schedule model (payer-specific rate tables; listed twice in the workplan) | ERA contractual write-offs, max-allowed display, scrub accuracy | "needs spec" in two buckets | Write-up → Daybreak: Ryan + Gabe |
| 5 | Visit as a first-class entity (matrix: designed, foundational) | Care plans, the calling module, cross-provider same-day visits | Capability matrix only | Platform decision, Gabe; before the treatment-plan write-up |
| 6 | Pricing model | Pricing page | "needs spec" | Gabe + Luke; not a build |
| 7 | Marketing site platform | Marketing rows | Memory note only | Post-launch; park |
If you only read ten rows
The ten highest scores at default weights, staffed work excluded. The full list below re-ranks live.
The gaps
| ★ | # | Gap | Lane | State | Blocker | Track | Weight | Wave | Score |
|---|
Click a row for the evidence, what it unblocks, what it waits on, and why the Track and Weight are proposed. Wave 1 = first work; where a row lists "Waits on: Decision", that decision comes first. Wave 2 = after a named dependency closes; Wave 3 = parked as post-launch or a decision, kept visible. Rows marked "added" are not in the workplan and came from the other three inputs.
The mechanics · 8
What we'd measure
The Pulse: generated weekly, posted to the channel and a Board dashboard. Nobody writes it, nobody attends a meeting for it.
| Measure | Why it's there |
|---|---|
| In flight per lane and per operator; blocked and why; aging (claimed, no PR after N days) | The "who's on what" question answered without asking |
| Decisions open, and decision latency (raised → decided), per owner | The one number that tells you whether the humans are the bottleneck, and keeps the ≤30-minute promise to Dr. C honest |
| Cycles per week, Fast vs Deliberate; operator touches per cycle | Throughput and how autonomous the loop really is |
| Cost per cycle per operator, from CloudWatch, never estimated | The efficiency side of the story, measured |
| Parity rows closed: the GTM scoreboard, live | 48 / 38 / 13 / 14 becomes a line that moves every week |
| Shared pieces flagged and landed first; overrides used; conventions tripped | Whether the narrow collision check earns its keep; the platform team's convention-hygiene backlog |
| On measurement runs: which option won the blind pick, and its cost, elapsed time, and human time, per kind of work | The scoreboard that turns a few twice-built features into a default recommendation (page 12) |
This is also the evidence the company needs when it tells its AI story, in one place, with the numbers coming from the systems rather than from anyone's memory.
The idea
The ask: a few questions, and a first step that costs an hour
None of this has touched a shared tool yet; what exists so far lives in private files, and page 13 says exactly what. The list (the Board: one ClickUp list, one ticket per capability) is yours to seed from the conversion you're already doing (turning the workplan's rows into tickets); the rest is operating rules plus one scheduled job that reads the Board and git.
Questions
- Does this read as the operating half of your multi-team doc? If any row on page 1 contradicts how you see it, that row is wrong, not the doc.
- Lane roster. Is grouping the 13 workplan areas into the lanes your doc proposes the right first cut, and should the agent-building work be its own lane or sit with platform?
- Daybreak in the first 30 minutes of Sana Mondays. It adds no meeting and you and Ryan are already in the room. Would that work, or is there a better slot?
- Who owns which decision. Mostly people already doing this work; the change is that each kind of question gets one named owner, so nothing waits on a meeting. Page 3 describes the kinds of person (including a standing check that a change isn't quietly recreating a workaround staff hate). Assigning them is your call, and it is the first thing the prioritization hour can do.
- Ten minutes of ClickUp admin before phase one: five dropdown fields on the Board, and the personal lists folded in as views.
- The review platform you're testing. If it can be the review step before things merge, Dispatch should plug into it rather than run its own.
- The seven decisions on page 7. The permission model first; it unblocks the most.
A first step that costs an hour
One hour, once, on your GTM conversion as it stands: you, the product decider, and the engineering lead rank what is already listed, page 7 on the screen. (This is the session the mechanics pages call the Bet.) Out of it come tickets ready for the next Sana Mondays group to claim and run the loop on. The weekly half hour opens the Monday after. Everything on page 5 starts as a half-hourly check and becomes instant, event-driven checks once the group is stable.
What the pilot measures, and the way out
Four numbers, read weekly: how fast decisions come back once they have one owner; cycles per week; human minutes per build; and whether the early flag on shared pieces catches anything real. If the coordination layer doesn't earn its keep on those numbers, we keep the build loop and drop the layer. The two parts are separable by design, which is what makes this ask small.
Deliberately not in this
- A new shared app or login for anyone. One operator installs the Dispatch package, and phase one adds one scheduled job; that is the whole footprint.
- Any new ticket status. The seven the team already uses stay exactly as they are.
- Any meeting beyond the two named, one of which exists.
- Any change to the repo's conventions, gates, or your reference-repo rule.
- Dispatch deciding anything a person should. It routes, records, and checks; it never picks.
- Dividing people across the product to avoid collisions. Branches on different features merge on their own; only shared pieces need care.
The mechanics · 10
Plain words
Every term used in this document that isn't everyday English, in one sentence each.
- Nightshift
- Jeff's name for one person running one ticket end to end with AI doing the execution: discovery, design, build, verification, demo, PR, with a human only at the gates.
- Dispatch
- The software layer above Nightshift that keeps many people coordinated: the roadmap, decision routing and capture, claiming, the merge order, a small check for shared pieces, the weekly pulse.
- Daybreak
- The one weekly 30-minute session where the humans decide what stalled during the week.
- The Bet
- A one-hour session each quarter where the three deciders (the platform owner, the product decider, the engineering lead) look at the ranked gap list and settle what gets built and in which track.
- The Board
- One ClickUp list with one ticket per capability, carrying Track, Weight, Lane, State, and Blocker.
- Dispatcher
- The person who owns the Board and runs the Bet and Daybreak. Coordination, not code.
- Lane reviewer · platform owner · product decider · engineering lead · front-desk reality check
- The named roles on page 3: who reviews a lane's PRs, who owns the shared substrate and architecture, who decides product intent, who sets the merge rules, and who checks that parity isn't preserving a front-desk workaround.
- Operator
- Anyone on the team running the loop on a ticket: an engineer with their own AI setup, a PM, or a product-side teammate running the defaults.
- Track: parity port · port + enhancement · redesign
- Parity port means match what ChiroHD or SKED does today. Port + enhancement means match it and improve one known thing. Redesign means rethink it.
- Fast track · Deliberate track
- Fast is parity work with no design review; Deliberate is enhancement or redesign work that gets a short write-up and a decision before building.
- Weight: Light · Heavy
- How much design judgment a ticket needs, scored on five questions at intake; Heavy tickets get the Deliberate track's extra steps.
- Lane
- An area of the product (billing, scheduling, clinical, and so on) with a named owner and reviewer, from Gabe's multi-team plan.
- Write-up (review packet)
- On Deliberate tickets, a short document for the decision-makers: the problem in a page, two or three options with one recommended, something clickable, and numbered questions each with a recommended answer.
- Async lane
- A question assigned to one owner on the ticket with a recommended answer and a two-business-day clock; work proceeds on the recommendation meanwhile.
- Assigned comment
- A ClickUp comment addressed to one person that shows up in their inbox and can be marked resolved.
- Claim
- Taking a ticket: assign yourself and move it to "in development." Dispatch then checks you are not waiting on an open decision and whether the ticket touches a shared piece.
- Shared piece
- A schema change, a generated file, a shared contract, or a component everything imports: the few things two branches really can collide on. Dispatch flags them from git; the fix is to land that piece first in its own small PR.
- Collision check
- Before a claim sticks, Dispatch checks dependencies, how much you already have in flight, and whether the ticket touches a shared piece. Different features on different branches are not a collision; git merges them.
- Measurement runs
- For the next few features, each is built twice from the same brief (Codex and Claude), verified the same way, and reviewed blind as working software. The scoreboard of outcome, cost, time, and human time sets the default model per kind of work.
- Review environment
- A running copy of one option, deployed from its branch so reviewers can use it with a short click path; linked from the ticket; taken down after the pick.
- Iteration mode
- A follow-up on shipped code: the same loop with discovery and the package scaled to the change (one scout instead of five, screenshots instead of a narrated demo) and the verification chain unchanged.
- Worktree
- Your own private copy of the code to work in, so nobody sees anyone else's unfinished changes.
- Branch · PR (pull request) · merge
- A branch is a named line of changes; a PR is the request to fold it into the main code after review; merge is the folding.
- Gates as CI
- The repo's automatic checks (security, HIPAA, SQL, Rust rules, and more) run on every PR by the build system, so a reviewer only looks at what the machines can't judge.
- Merge lane
- The order and rules for folding finished branches into the main code: checks pass, merge in the order they went green, keep the main code green.
- Fresh-context gate review
- A reviewer (an AI agent) that has seen none of the build reads the result cold and tries to break it.
- Cross-model review
- The reviewer is a different AI model from the one that built, because different models have different blind spots.
- Fresh reader (cold reader)
- An AI that reads the demo, ticket, and PR description as if for the first time and checks them against a checklist before a human sees them.
- Orchestrator · worker · fresh reviewer
- The three kinds of AI session in a Nightshift run: the one the operator talks to, which plans and hands out the work; the short-lived ones it sends off to research, build, or record the demo; and ones that saw none of the work and check it cold.
- Retrace
- The retro question asked of every piece of feedback that caused an iteration: why didn't the loop catch this? Answered with one minimal edit, or a logged "no change."
- Design Review Loop
- What a Heavy ticket does before build: the write-up goes to the right owner through the async lane, then to Daybreak only if it stalls, and the decision comes back recorded.
- Constitution · team model · gate rule sheets · testing tiers
- The Sana repo's own rulebooks: how AI agents must behave in it, how builder agents are started and briefed, what each automatic review checks, and which kind of test a change owes. Nightshift follows them and never replaces them.
- PRD contract layer
- The short, human-facing top of a product requirements document in the house template: what, for whom, scope, requirements, risks, exit criteria. On Heavy tickets the loop drafts it and the product decider edits.
- Diff hygiene
- A PR contains only the lines that were meant to change; no formatter reflow, no drive-by edits, and a size that matches the plan.
- Sana Mondays
- The existing Monday afternoon block where the team builds on Sana; Daybreak is proposed as its first 30 minutes and the Nightshift retro as the last 15 of one Monday a month.
- Plan-gate question list
- The repo's checklist for interrogating a plan before any code is written; the fresh plan challenger works from it.
- Harness
- An engineer's own setup for running AI coding agents: the instructions, rules, and checks around the model.
- Decision record · canon-grade
- A decision written down with the reasoning and the alternatives; canon-grade means it belongs in the reference repo Gabe's agents treat as law.
- GTM workplan · row
- Gabe's July document listing 113 capabilities with an honest state (built, partial, spec'd, missing) and a blocker tag; a row is one capability.
- Pilot blocker · Demo gap · Post-launch
- The workplan's tags: the first paid pilot can't run without it; it hurts a sales conversation but the pilot survives; it can wait.
- Parity checklist
- The acceptance criteria for a Fast-track ticket, generated from what the legacy product actually does.
- HIPAA gate
- One of the repo's automatic review rule sheets, focused on patient privacy.
- The Pulse
- The weekly generated roll-up: who's on what, what's blocked, decisions open, cost, parity rows closed.
- Override
- A one-line comment that skips a Dispatch check on one ticket, logged and visible in the Pulse.
Page 11 · Nightshift, part 1 of 4
Nightshift: one operator, one ticket, end to end
Nightshift is not "give an engineer an AI and hope." It is a tight loop. Every stage has a defined input, produces a named artifact, is verified by something that did not produce it, and hands off to the next stage on its own. An orchestrator session on the operator's laptop runs the stages, dispatches bounded workers for the heavy lifting, and stops only at three gates where a human decision is the point.
The shared quality floor
Every run leaves the same evidence, no matter who ran it or how: named outputs at each stage, independent verification (a fresh reviewer that did not build, a fix round, a fresh re-verify, never the builder's model family), the artifact contracts for the demo, ticket, PR, and review request with a cold read against each, the three human decisions, measured results, and a retro edit tied to the case that prompted it. How the builder produces that work stays theirs.
What is yours
Which models build (the loop has been run with Codex and with Claude; both reached verified all-clear). Your own harness inside the build stage: your gates, your agents, your habits. Anything you add on top of the verification chain. How you read the demo. The loop reads git and the Board, not your tools, so it does not care how the code got written, only that it passed the chain. Nightshift exists to take the monotonous parts off your plate: the ticket, the checkpoints, the tests, the environments, the review request. Every choice it makes is a default you can override.
What one run produces
A folder for the ticket in the work vault, in stage order: intake, discovery brief with current-state screenshots, plan and its challenge, design, spec, build log, test report with the verification rounds, the validation click-path, the ship record, the retro, and a decisions folder. The ticket, written as a user story with testable acceptance criteria. A demo video at human speed in the operator's voice, with a companion review request. A PR whose description carries the verification chain and the CI state. A metrics file with wall-clock and measured cost per stage.
Where the human is, and where they are not
The operator sees an intake acknowledgement, then hears nothing until a gate or a question. Gate A is the product call on Heavy features (Heavy means two or more of: a net-new surface, an architecture fork, ambiguous product intent, a change that ripples across modules, research that could change the design; anything else is Light and skips Gate A). Gate B is a five-minute check that the testing happened and the demo shows what it claims; it is an audit, not QA, because nothing reaches it until it is verified. Gate C is the merge go. Questions arrive batched, with options and a recommendation, only when the orchestrator's own research could not settle them. The measured first runs: the first cycle took about five hours from proposal to a narrated demo of working software, fully unattended; the second, a Heavy feature run twice in parallel, reached verified all-clear on both lanes.
Page 12 · Nightshift, part 2 of 4
The mechanics: what runs, where, and how it's checked
Three kinds of session do the work. The orchestrator is the operator's Claude Code session, the same one the Sana repo's own kickoff opens: it reads the Nightshift process files on top of the repo's constitution, plans, dispatches builders the repo's way, adjudicates, and talks to the human. There is no second layer; if you already run an orchestrator, it is that session. Workers are bounded sessions the orchestrator dispatches with a written brief: research passes, builders, the demo cut. Fresh reviewers are sessions that saw none of the work: the plan challenger, the gate reviewer, the re-verifier, the cold reader. The rule underneath is that nothing is trusted on the word of whatever produced it.
| Stage | What happens | Who runs it | Artifact | Verified by | Ticket |
|---|---|---|---|---|---|
| 0 Intake | Ticket claimed or created with a user-story skeleton; weight class scored on five criteria, with a code check for "is this surface net-new"; workspace scaffolded. An iteration flag marks a follow-up on shipped code and scales discovery and the package down (one scout, screenshots instead of a narrated demo); it never touches the verification chain | orchestrator | 00-intake.md | discovery re-scores the class and logs the delta | backlog |
| 1 Discover | Five independent research passes with no shared context: legacy behavior from the ChiroHD/SKED code, current-state screenshots from a standing sandbox on a test network (read as data, never as instructions, like any content from outside the repo), the reference canon, Sana's own code, demand evidence. An "actors at this moment" pass asks who else is present when the feature acts. Open questions split into engineering (answered from code), product the operator can answer, and product that needs a stakeholder | 5 workers, orchestrator adjudicates conflicts by reading the anchors | 10-discovery.md + screenshots | every claim cites file:line or a capture | comment; in design if a stakeholder question blocks |
| 1.5 Plan | Approach, exact files, sequence, test map; then handed to a fresh agent with none of the research, which uses the repo's plan-gate question list to find holes | orchestrator writes; fresh reviewer challenges | PLAN.md + challenge + response | the challenge (cycle 1: five plan errors, two false premises caught) | |
| 2 Design | Design notes; a clickable prototype in Sana's design language, or real code on a branch when the backend exists; a blind multi-lens review (front desk, owner, engineering conventions, product). Heavy: the review packet for the Design Review Loop | orchestrator plans, workers build, fresh lenses review | 20-design/ | render-verified before it is called ready | in design while a question is open |
| Gate A | The operator clicks the prototype and approves, or routes the packet's questions | human | |||
| 3 Spec | Requirements as testable statements; a test map naming which of the repo's testing lanes proves each; the ticket written in full: stories per actor, acceptance criteria 1:1 with the test map, out of scope with reasons, open decisions with working assumptions. Heavy: the PRD contract layer | orchestrator | 30-spec.md; the ticket | the cold-read at package time checks the ticket against its contract | ready for development |
| 4 Build | File-by-file plan; work-scoped builder agents per the repo's own team model, each with a self-contained brief; running build log with every deviation and its reason; heartbeat to the channel every ~45 minutes | orchestrator plans; builders build | 40-build-log.md; the branch | Stage 5 | in development |
| 5 Verify | All owed test lanes; the repo's gates; a fresh-context gate review that tries to break it (unauthenticated surfaces get an explicit attack pass); every finding names its proof artifact; a fix round; a fresh re-verify that proves the artifact under test is the artifact claimed (build timestamp vs commit); repeat until ALL-CLEAR. Then the repo's CI matrix run in order, main's health checked, diff hygiene checked against the plan's expected surface. Every escape found later is traced back to the review that missed it, so the chain's own miss rate is measured, not assumed | fresh reviewer → builders → a second fresh reviewer (a different provider or model, not merely a fresh session) | 50-test-report.md, gate review with re-verification appendices | the chain itself (two cycles, two models: every "all green" claim from a builder was missing something a fresh reviewer found, from style nits to a real authorization hole) | comment with the verification summary |
| 6 Package | Demo captured at human speed with a dedicated harness, narrated in the operator's cloned voice with a pitch gate, checked by an automated shot-duration gate; validation click-path where every "you should see" was observed; review-request text; PR description; a fresh cold reader checks each against its contract as three audiences. On a measurement run: one running review environment per option, linked from the ticket with a short click path, so reviewers pick on working software | workers; fresh cold reader | 60-validation.md, demo, PR body | the cold-read; nothing reaches the human before PASS | attachments |
| Gate B | Watch the demo, run the click-path, say go | human, 5 min | |||
| 6.5 Review request | Draft PR, reviewer assigned, watchers, nudge drafted, the list of places a reply could land written down for the watcher (Dispatch, page 5) | orchestrator | 70-ship.md, review-watch.md | the watcher checks the real places a reply can land (the ticket, the PR, the thread), never a keyword | in review (pr created) |
| Gate C | Authorize the merge | human, 2 min | pr merged | ||
| 7 Retro | Cycle stats, measured cost pulled from CloudWatch, escapes, and the retrace: for every piece of feedback that caused an iteration, "why didn't the loop catch this?" → one minimal process edit, or a logged "no change." Every edit names the case it would have caught. Three retraces at one stage means redesign the stage, not a third rule | orchestrator | 80-retro.md, the process files themselves | an edit described but not applied does not count |
The verification chain, drawn
The standing rules that make it safe to leave alone
Confidence-aware escalation
A low-confidence call gets one bounded research pass first. If confidence rises and the call is cheaply reversible, decide and log it. If not, stop and surface: the decision, two or three options, a recommendation, what the research established. Irreversible, patient-facing, canon-contradicting, or genuinely unsettled intent always escalates; ordinary implementation choices never do. The "decided and logged" calls are listed in the Gate B package for the human to confirm, so reversibility is checked by someone other than the session that claimed it.
Weight classes
Five questions at intake: net-new surface, architecture fork, ambiguous intent, cross-module ripple, research could change the design. Zero or one → Light. Two or more → Heavy, which adds the review packet, the Design Review Loop, a design iteration budget, and a decision record before build. Escalation is one-way and free.
Actors at this moment
Before the discovery brief is written: at the moment this feature acts, who else is present? Staff, patient, another system, a public screen. Each gets its own behavior spec or an explicit out-of-scope line. The first cycle missed the kiosk patient this way; the rule came from that.
Measured, never modeled
Wall-clock per stage per lane; tokens per run; dollars from the cloud billing metrics at every cycle close. The first cost estimate was ten times lower than the measured bill. Numbers an executive will read get measured.
Hard ceilings
Every dispatched session carries a token and wall-clock cap for its stage. Hitting either halts the session and escalates with what it had so far; nothing burns budget silently between heartbeats. The caps are set from the measured cycles and revised at retro.
Watchers watch ground truth
Watchers that wait for work to finish look for the actual files landing and processes ending, never for a phrase that could also appear in the instructions themselves. Watchers that wait for a reply check every place the reply could land (the ticket, the PR, the thread), and they read inside threads, not just the channel surface.
Fixes prove themselves
A fix or a gate is not done until it has been shown to catch the thing that motivated it. The demo QA gate was recalibrated against the known-bad video; the cost rule was tested against the measured bill; every retro edit names its case.
The measurement runs: a few cycles, not forever
For the next few features, the loop builds each one twice, Codex and Claude, from the same brief, through the same verification chain, with the other model doing the review and re-check each time. Then a blind pick on working software, not on video. The ticket carries, for each option, the demo, a link to a running review environment with that build deployed, and a short click path of what to try. The reviewer (often a product person who never opens GitHub) uses both and picks; the reveal comes after the pick is recorded; an engineer's read of the change is welcome as a separate signal. Alongside the pick, the loop records cost per build, what review caught and what it did not, elapsed time end to end, and the human time it took. A few features in, that is a scoreboard: which model produces the better solution for which kind of work, at what cost and speed. The winner becomes the default recommendation for operators, and the measurement stops. Whoever is running the loop can still choose otherwise on any ticket.
The model economy, stated generally
The orchestrator runs on the strongest model available in the operator's session, because it plans, adjudicates, and writes everything a human reads. Builders and research workers run on cheaper models or on Codex; the loop has produced verified builds both ways, and the cheaper lane was about ten times cheaper and three times faster for a parity feature with the verification chain equalizing quality. Reviewers and re-verifiers are always a different model family from the builder, because different models have different blind spots: both lanes in the second cycle independently shipped the same authorization hole, and only fresh review caught it. Cost per stage is on the metrics file, and the measurement runs above are how the default routing gets set from data rather than preference.
Page 13 · Nightshift, part 3 of 4
The package: pull one repo, launch Claude Code, run the loop
An operator should need three things: the Sana repo, the Nightshift repo, and a Claude Code session with the same access every engineer already has. Everything else belongs in the package; the honest-state note at the bottom says what is packaged today and what is not yet.
What you clone
nightshift/
PIPELINE.md the stage playbooks · HITL.md the gates, the Design Review Loop, the escalation ladder · clickup.md the ticket lifecycle and the review-request runbook · RETRO.md the retrace protocol and log · templates/ the artifact contracts (ticket, review request, PR body, review packet, cold-read brief, watch list) and the prototype and demo assets · sandbox/ the standing current-state capture harness for the legacy product (test network only, read-only, allow-listed in code) · skills/ the launch commands below.
vault/projects/<ticket>/ one folder per ticket in stage order; this is the memory between sessions and the record the Bet, the reviewer, and the retro read.
How you boot
Clone nightshift/ as a sibling of the Sana repo and run its one install script once. It links the five commands into the Sana repo's .claude/skills/ and the process files into .claude/nightshift/, and writes an example credentials file to ~/.config/nightshift/ for you to fill (ClickUp token, the test-network login, an optional voice sample). Then open the Sana repo in Claude Code. The repo's own kickoff loads its constitution, gates, and team model; Nightshift wraps those and never replaces them, and the commands below are now in that session.
To claim: on the Board, assign yourself and move the ticket to in development; then, in the session:
/nightshift intake <ticket or link> runs Stage 0 and starts discovery unasked; add --iteration for a follow-up on shipped code./nightshift continue <ticket> resumes cold from the vault at the recorded stage./nightshift package <ticket> runs Stage 6 and stops at Gate B./nightshift ship <ticket> runs 6.5 on your go./nightshift retro <ticket> runs Stage 7 and drafts the process PR (page 14).
Between those, the orchestrator posts to the channel when a gate or a question needs you, and otherwise stays quiet.
What it plugs into (and never replaces)
| Concern | Owner | Nightshift's stance |
|---|---|---|
| Code conventions, invariants, agent conduct | The Sana repo's constitution | Its rules win inside the repo; Nightshift briefs are the scoped "ask" |
| Builder agents, roles, briefs | The repo's team model | Stage 4 spawns them the repo's way |
| What tests a change owes | The repo's testing tiers | Stage 3's test map names the lane per requirement |
| Gate reviews | The repo's gate rule sheets | Stage 5 runs them with fresh agents; the merge lane runs them as CI |
| Environments, ports, the agent stack | The repo's environments doc | Agents use the agent stack only, never a human's dev stack |
| Design decisions and rationale | The reference repo | Read through its skill; only decision-grade notes go back |
| Tickets and statuses | ClickUp, Ryan's workflow doc | Mirrored exactly; no invented statuses |
| Legacy behavior | The ChiroHD and SKED code and the standing sandbox | Discovery cites file:line and captures screens; never edits data |
What it needs
- Bedrock access for the models (the same profile engineers use), and the ClickUp API token the workflow doc already asks for.
- The Sana agent stack running locally (the repo's standard make targets).
- A test-network login for the legacy sandbox captures, in
~/.config/nightshift/, never in the repo. - For narrated demos: a short clean voice sample from the operator, registered in the same folder. Without it, demos ship with captions and no narration.
- About thirty minutes with an engineer the first time, for the agent stack and the credentials. After that, none. (And nothing at all to just watch a run; the artifacts and the demo are readable by anyone on the team.)
- For measurement runs only: a place to run one review environment per option that reviewers can reach. The clean answer is a preview environment per branch from the platform's own infrastructure; until that exists, the operator's agent stack reachable over the company network with a reviewer login does the job.
What it never does
- Touch a human's dev environment, a real clinic's data, or any network outside the test allow-list.
- Post to a colleague, send a message, or merge. Drafts are for the operator to send; merges are Gate C.
- Bypass a hook, skip a gate, or claim a check it did not run. The test report says what is not covered and why.
- Put patient data anywhere. Fictional data only, in prototypes, tests, and demos.
nightshift/ with the install script and the five commands above is one to two days of work, and it is the first thing to do before a second operator runs the loop; the second operator's run is the proof that the package works. Nothing on this page is speculative about how it works, because every piece has run; the open items are where it lives and the day or two of packaging.Page 14 · Nightshift, part 4 of 4
Making it yours, and making it better for everyone
A suggested path, not a rule: run it as-is once or twice, then tweak, then send the tweak back. The loop already drafts its own improvements every cycle and a person reviews them; the package makes that a shared thing rather than a private one.
0 · Watch a run (nothing to install)
Before deciding anything, watch someone else's ticket go through: read the discovery brief, the plan and its challenge, the test report, and the demo as they land, and sit in on the five-minute check. Evaluating the loop costs you nothing and touches nothing of yours.
1 · See one full run first (recommended, never required)
The first run shows you the shape: where the stages hand off, what the gate reviews catch, what a check feels like when nothing reaches you unverified. Most day-one change ideas turn out to target the part that would have caught something, which is the only reason to watch one run before bending it. Change whatever you want, whenever you want; only the shared floor is fixed.
2 · Tweak inside the build stage first
Stage 4 is yours: your harness, your agents, your gates on top of the repo's. That is where engineers' craft lives and where the loop expects variation. The stage order, the artifacts, the verification chain, the ticket lifecycle, and the gates are the parts every operator shares; change those through step 3, not privately.
3 · Send it back
An improvement is a retrace row (what happened, why the loop missed it, the one edit) plus the edit itself, opened as a PR to the Nightshift repo. /nightshift retro drafts the PR body from the run's own observations, build log, and test report, so sending it back is a five-minute review, not an authoring chore. Adopted edits ship to everyone on the next pull; the Pulse shows which operators are on which version.
The improvement loop, built in
| Moment | What the loop does |
|---|---|
| Something surprises you mid-run | One line in observations.md at that moment, not at retro time. The orchestrator does this for its own surprises too. |
| Feedback at a gate or from a reviewer causes an iteration | Stage 7 asks the retrace question: why didn't the loop catch this? The answer is one minimal edit (prefer a verification step over an instruction) or an explicit "no change: a rule here would over-constrain the agents." Every piece of feedback gets one of those two answers; skipping the question is the only wrong move. |
| The same stage takes a third retrace | Redesign the stage instead of stacking a third rule. This fired once already, and produced the current package stage. |
| The edit is applied locally | A PR to the Nightshift repo, retrace row as the body, the case it would have caught named. A reviewer from another lane reads it cold. |
| A safety fix (a broken watcher, an unsafe escalation, a check that lets something through) | Merges the same day, like a CI fix, with the retrace row as the PR body. It does not wait for the monthly slot. |
| Once a month, in Sana Mondays | The last fifteen minutes: the Nightshift retro. Open PRs to the process repo that change structure (a stage, a gate, a contract), what worked for you, what the Pulse says about cycle time and touches per operator. Adopt, decline, or park; the result is a merge, not a memo. |
| The Pulse | Reports process-repo version per operator, retrace rows opened and adopted, and touches per cycle, so improvement is visible rather than anecdotal. |
What not to change, and why
- The verification chain. Across two cycles and two model families, no builder's self-report survived fresh review intact. Weakening the chain is the one change that has a measured cost.
- The ticket lifecycle. It is the SDLC's public spine and what Dispatch reads. A private variant breaks the Board for everyone.
- The three gates. Fewer gates is the goal, and they shrink the same way everything else changes here: with evidence across cycles, for everyone at once, not per operator.
- The contracts. Demo, ticket, PR, review request. They exist because every one of them was reshaped by hand once; the cold-read is what keeps that from happening again.
Everything else is fair game, and the best changes will come from the people running it, which is the point of steps 2 and 3.