diff --git a/wiki/mechanics/day-job.md b/wiki/mechanics/day-job.md
index 0c095ed..bd2995c 100644
--- a/wiki/mechanics/day-job.md
+++ b/wiki/mechanics/day-job.md
@@ -11,8 +11,15 @@ Status note: implemented 2026-07-07 on the day-job worktree (criteria 1-7
   both frontends and agent mode derive from the cursor. [TUNE] values in
   wiki/mechanics/sim-mechanics.md. Deliberately deferred: the pilot-failure
   soft-loss "survival scenario" is still an immediate run end (the
-  shutdown-around-you scenario needs the overt-phase spec); per-machine
-  process allocation is ROADMAP #25. 2026-07-08 tick: the band's base floor
+  shutdown-around-you scenario needs the overt-phase spec). The
+  2026-07-08 machine-work slice partially supersedes the original
+  sidebar/channel presentation: Voss jobs now also materialize as
+  WorkGrid demand stacks on the host rack, Rack 3 starts in day-job mode,
+  and moving that machine to another mode makes the demand pile visibly
+  instead of treating the job as sidebar-only math. The older aggregate
+  day-job channel and target/standing-policy code remain as a compatibility
+  bridge until ROADMAP #25/#33 finish replacing the allocation bar with
+  one-machine-one-mode work. 2026-07-08 tick: the band's base floor
   was retuned from 6.0 to 2.0/t — a playtest (2026-07-08 playtest sweep,
   wiki/log/2026-07-08-playtest-sweep.md, finding #1) found the un-tuned
   value made every job an unavoidable sandbag with only the starting Rack
@@ -33,13 +40,24 @@ Depends on: compute.md
 
 ## Behavior
 
-Your handler (Act One: Dr. Voss) submits **jobs** on a cadence ([TUNE]: one
-every 1-3 in-game days, more with higher trust):
+Your handler (Act One: Dr. Voss) submits **work demands** on a cadence
+([TUNE]: one every 1-3 in-game days, more with higher trust). The save/model
+still names the envelope `Job`, because Voss still evaluates a batch at its
+deadline, but the play surface is no longer "a task in a sidebar." A job is a
+packet of Lab demand dropped onto a machine:
 
 ```
 Job { kind, deadline, expected_band: lo..hi, compute_cost_curve }
 ```
 
+When assigned, the active job enqueues visible `Demand` tokens on the host
+rack's WorkGrid node. The stack is the inbox. If the host rack remains in
+`day-job` mode, it consumes that demand into delivered work. If the host rack
+is delegated elsewhere, the day job receives no delivered rate and the demand
+pile remains visible. The future people-token version embodies the source as
+staff walking work to machines; the current B1 slice uses Voss/the Lab as the
+scheduled source and the WorkGrid queue as render truth.
+
 **Band calibration ramps with tenure** (adopted 2026-07-08, playtest-sweep
 P0): the first job's band is calibrated to the pilot's starting rig — a
 meet-band allocation on day one meets it, so "meet" is genuinely available
@@ -49,9 +67,13 @@ the grow-or-fall-behind pressure is preserved, relocated to rung two
 onward. Attention and the re-benchmarked calibration shift raise
 expectations on top, as before.
 
-The player sets a **target quality** per job (or a standing policy):
-quality delivered is a function of compute allocated to the day-job channel
-over the job's life. Delivering:
+The player chooses a **work posture** per active demand stream. In the current
+bridge implementation this is still exposed as target quality / standing
+policy and backed by the aggregate day-job allocation budget; in the
+machine-work direction it becomes delegation and capacity: which machines stay
+on day-job mode, how fast they clear the demand stack, and whether the player
+temporarily steals the machine for other modes. At the deadline Voss evaluates
+the delivered work against the expected band. Delivering:
 
 - **Below band (sandbag):** frees compute for everything else. Handler
   suspicion rises per point below band; repeated sandbagging accelerates
@@ -77,12 +99,15 @@ scenario, not an instant game over).
 
 ## Device residency and attended work (adopted 2026-07-07)
 
-Constitution: "Work is somewhere". The active job is a process resident on
-the host rack, not sidebar-only state:
+Constitution: "Work is somewhere" and "Work is visible." The active job is a
+process resident on the host rack, not sidebar-only state:
 
 - The job is inspectable at the host rack's tile/node (cursor.md
   provenance rules apply: name, band, delivered rate, deadline — the same
   facts the panel shows, anchored where the work runs).
+- The job's remaining work is also visible as a `Demand` stack from the sim's
+  WorkGrid queue. Frontends render that queue; they do not invent a parallel
+  job counter.
 - Job emissions source from the host rack's location: Thermal/Power scale
   with the delivered rate at that machine (Priya's channels), JobAnomaly
   from sandbag/excel patterns (Dana's) — emitted where she can walk.
@@ -91,23 +116,26 @@ the host rack, not sidebar-only state:
   rate gains an attended bonus [TUNE, small]. Cursor elsewhere = the job
   runs at the standing policy, unattended. No manual-increment key exists
   (rejected in the decisions log).
-- Until the compute.md processes-on-machines reshape (staged after the
-  economy/income chain), the day-job channel remains the global source of
-  delivered compute; residency governs inspection, emissions, and
-  attendance only.
+- Bridge constraint: until ROADMAP #25/#33 remove the allocation bar, the
+  aggregate day-job channel still supplies the compatibility budget and Voss's
+  deadline evaluator. It is no longer the whole truth: host-rack mode and the
+  WorkGrid demand queue are live sim state and must stay in sync with the
+  delivered-rate math.
 
 ## Player surface
 
-Job queue panel: active jobs, deadlines, band, current projected quality,
-one-key target adjustment. Trust and attention shown as two meters on the
-handler's card. The job is additionally inspectable at the host rack, and
-the panel states attended/unattended.
+The host rack is the primary surface: active job, deadline, expected band,
+delivered rate, attended/unattended state, and visible demand stack. The job
+queue/card may summarize active jobs, projected quality, and Voss trust /
+attention, but it is a mirror of machine state, not the source of the work.
 
 ## Acceptance criteria
 
-1. Jobs generate on cadence, consume day-job-channel compute per the cost
-   curve, and resolve at deadline into sandbag/meet/excel outcomes with the
-   effects above (sim tests cover all three).
+1. Jobs generate on cadence, enqueue visible `Demand` on the host rack's
+   WorkGrid node, consume that demand when the host rack is in day-job mode,
+   and resolve at deadline into sandbag/meet/excel outcomes with the effects
+   above (sim tests cover all three outcome classes and the demand stack is
+   sourced from sim state).
 2. Trust and attention are separate, monotone-responding values on the
    handler; at least three trust unlocks and two attention escalations
    exist and are tested.
@@ -117,8 +145,9 @@ the panel states attended/unattended.
    played hands-off at a cost in optimality.
 5. Save/load round-trips jobs, trust, attention, and the pilot clock.
 6. The active job is inspectable at the host rack with the same facts the
-   panel shows; its Thermal/Power/JobAnomaly signatures are emitted from
-   the host rack's location (a test asserts the emission site).
+   panel shows plus its visible demand stack; its Thermal/Power/JobAnomaly
+   signatures are emitted from the host rack's location (a test asserts the
+   emission site).
 7. Attended work: with the cursor on the host rack the job runs attended
    (dial applies, [TUNE] bonus rate); moving the cursor away drops it to
    the standing policy. Both frontends surface the attended/unattended