This is the filed review document, copied at 09:19 EDT. Its dated claims remain historical. See the current update before acting on an old sign-in request or delivery status. Reply in chat with decisions or feedback.
JR implementation slices
These are proposed implementation tickets under WOB-75, derived from the 20 October spec. Creating the tickets does not release JR's runtime hold. The implementation owner takes each slice only after its stated dependencies and the later build authorization are satisfied. The spec holds the rationale; each slice states what it builds and what proves it.
All six were filed as Backlog proposals on 20 October. Scope/access and later authorization dependencies in their bodies remain in addition to these implementation edges.
JR1 · Continue one scoped Slack conversation through WobOS
Delivers: a permitted request in a verified self-only Slack destination creates durable Work, returns a source-linked answer and continues after a controlled restart.
Blocked by: WOB-45's installed usable foundation; source-reviewed Slack transport and actual app grants; later JR implementation authorization.
Resolve the real actor and destination before admitting source material.
Retain native event, thread and message IDs. A replayed event ID is acknowledged without a second input or Work.
Save each admitted event's receipt and its pending input in Bolt global middleware, under the Work's lock, before any acknowledgment. This covers events and interactive payloads. Measure the save against the three-second interactive budget.
Create the Work by exclusive create from the first message's thread. Treat that create's refusal as either a replay or a lost race, as the spec's replay rule describes, and never drop the event.
Add the pending_inputs list (queued, in_turn, done) as new work under the existing lock. The current pending_ask holds one value and is not a queue.
Keep Slack actor IDs in a per-input field, separate from author.
Reuse WobOS's SDK adapter and single-owner session claim.
Run with production memory off and preserve unrelated job holds.
Demonstrate the real application entry, reply readback, a failed save (no acknowledgment), an interrupted turn and continuation with the adopted SDK version. No team send is required for this first proof. Fake-client runs prove the receipt logic only, and are labelled that way.
Record installed versus candidate behavior and exact rollback through the installation path the build owner names.
JR2 · Route and continue multi-person JA work without crossing audiences
Delivers: two unrelated jobs in one channel remain separate; multiple authorized people continue one thread; an audience change starts a correctly scoped continuation.
Blocked by: JR1.
A known thread resolves through linked_threads on its Work. An unknown thread triggers a bounded scan of the permitted open Work records in the same workspace and channel, and the choice receipt records the scan count. Add no index unless the measured count shows a real need.
New requests use one JEV choice among only authorized active work summaries, plus new/none.
Preserve every contributing actor; a later speaker does not inherit the first person's restricted authority.
Ambiguous references produce a bounded stronger check or one useful clarification.
Build ordered pending inputs: an input arriving during a running turn queues and runs after it. Restart reconciles the saved provider acceptance; a crash before that acceptance is recorded may replay a model turn, as the spec explains. Existing action receipts prevent that replay from repeating an outward effect.
Refresh membership before context injection and delivery. A provider conversation exposed to now-disallowed material is not resumed for the new audience. A membership event that arrives after the read holds further sends in that thread and rebuilds the context. The membership-read-to-send race is disclosed, not closed.
Demonstrate concurrency, stale edits, a membership change and cross-thread reference using bounded self-only/disposable fixtures before any authorized team trial.
JR3 · Make and read back a teammate's permitted task change
Delivers: a teammate can request progress, completion or an explicit due-date change on their own existing Slack List item; another person's task yields a reviewable proposal.
Blocked by: JR2; native Slack Lists access established for the intended unattended runtime.
Resolve the actual List item and re-read its owner immediately before the requested write.
Apply WOB-72's existing scope without creating another permission system.
Bind approvals and interactions to actor, Work, destination, exact content and revision.
Reconcile uncertain native outcomes before retrying.
Update only requested cells after a fresh owner/value read. Slack Lists have no atomic revision precondition, so a human edit between that read and the write is not caught. Demonstrate and disclose that remaining race.
Demonstrate own-item read/write/readback, another-owner refusal and stale-draft refusal in the approved isolated test area.
Keep unknown due dates blank and current task state in its owning List.
JR4 · Carry a current source review back to the original work
Delivers: JR can investigate an actual JA document or meeting and return a corrected, attributed answer to the requesting Work and the permitted Wob handoff.
Blocked by: JR2. Wispr-sourced capture additionally depends on WOB-120/121; an existing document path can qualify independently.
Select current permitted sources and record fetched versus interpreted coverage.
Keep transcript, uncertain speaker labels and personal debrief attribution distinct.
Apply the later W03 allowance for task-relevant personal-line discovery; no Apple pre-tag prerequisite.
A corrected source invalidates affected pending context and actions.
Reuse the established JA meeting/Drive homes and original request linkage.
Demonstrate one real complete source review, a correction, a private passage exclusion and consumer readback. Preserve contrary results and actual usage.
JR5 · Prove selective JA memory before any activation
Delivers: a later permitted Work can use relevant JA craft without retrieving another audience's information.
Keep the recorded captain / justanother mapping (ledger row 63); do not invent a new memory service.
Use an isolated test workspace for real write/recall/correction proof.
Demonstrate that stored audience labels are actually enforced before any restricted candidate can be written.
Read the peer's current derivation settings (dreaming, deriver and card rewriting) before activation, and record them with the activation decision. Test that a restricted-audience session writes no derived conclusion into the shared peer, and that every read filters derived and seeded items alike.
Current task statuses remain outside seed memory.
Keep both production switches false until the separately authorized activation step.
Show native later-Work recall, denied cross-audience retrieval, stale-source correction and complete owned-test cleanup. Source review and fake clients do not close this slice.
JR6 · Deliver useful follow-through and an authorized team trial
Delivers: JR makes a useful source-backed follow-up, sends the agreed owner Slack digest, hands a JA development to Wob and turns a real correction into an actionable repair.
Blocked by: JR3 and JR4; an expressly authorized team trial and later activation choice. JR5 is required only for the parts that claim production memory behavior.
Reconcile the saved JA job inventory and its actual holds; enable only the separately authorized returning jobs.
Reuse Work and the owning tasks for due changes and requested progress, with no invented timer cadence.
Exercise the multi-person, unrelated-work, finance-audience, task-owner, interruption and meeting-correction scenarios in the spec.
Record which commands were loaded, which triggers fired and what people actually received.
File a real failure or natural correction into Squeaky with the source conversation and read back its repair outcome.
Keep the owner DM and Wob personal phone responsibilities distinct.
Ownership when the build starts
Astra's JA proposal lane owns this spec, these tickets and the seed proposal. The build owner for WobOS's shared core, channel integration, configuration and installation is named by the coordinator when the build starts; this document does not assign it. Slack app grant requests and host or tool registrations belong to the Claude desktop integration lane. Any reserved action code that runs in the cloud stays with the cloud reserved action code lane. A JR implementation worker needs an explicit named-file transfer at a pinned base before editing WobOS surfaces. JA source, meeting and seed artifacts stay with their owning records. A Slack Lists permission gap blocks JR3, while source-backed conversation and routing work can proceed when their own dependencies are met.
The spec owner maintains these descriptions and native tracker dependencies together. These six slices are proposed and unstarted; no acceptance checkbox is a claim of implementation.