Team role-queue and Temporal execution specification

Team role-queue and Temporal execution specification

Date: 2026-08-19
Revision: R2
Status: RECONCILED_DESIGN_CANDIDATE_READY_FOR_IMMUTABLE_REVIEW
Authority/effect: none; this document does not bind roles, admit work, mutate Jira, grant effects,
start Temporal, or amend the adopted team charter
Purpose: specify how role-bound agents, durable work custody, role queues, automated validation,
independent review, effects, knowledge handover, and restart recovery should compose into one
efficient operating system

1. Executive decision

The desired operating model is achievable, but it is not one feature and it is not yet an
end-to-end operational capability. The repository contains strong pieces:

• a ten-role/eight-seat runtime profile with primary and compatible secondary roles;
• a one-action team-resume command and structural seat lifecycle tests;
• an explicit separation of role willingness, role authority, work custody, review, certification,

and effect authority;

• a Jira-as-projection decision;
• a work-router implementation that is a useful source donor;
• Temporal/NATS laboratory contracts, role queues, runtime adapters, receipts, and reconciliation

policy seams; and

• Quality Fabric, deterministic tests, contract checks, supply checks, and BDV-related design input.

The missing capability is an integrated and adopted execution control plane. It must join:

adopted outcome
  -> role-neutral work packet
  -> fenced role custody
  -> exact implementation candidate
  -> automatic validation evidence
  -> independent review
  -> evidence certification
  -> separately authorized effect
  -> authenticated observation
  -> durable knowledge handover
  -> closure with deterministic re-entry

The main build is therefore an authoritative work-control kernel plus a production-shaped Temporal
workflow. Temporal, Jira, the coordination channel, and Cortex remain consumers or coordinators of
that truth; none becomes authority merely by recording or replaying it.

R1 incorporated the review feedback recorded at coordination-channel sequences 4578-4595. R2 adds
the Operator-requested elastic-seat and adaptive-capacity model without weakening the R1 controls.
The exact R1 dispositions are in
delivery/team-role-queue-temporal-execution/REVIEW-RECONCILIATION.md. R1 is a finalized design
candidate, not an adopted operating baseline; R2 is its successor candidate. R2 must be frozen as one immutable package,
independently rebound, accepted through the governing process, and implemented before it can direct
live work.

2. Source basis and precedence

This candidate follows the repository authority order in README.md and is bounded by:

• CONDUIR-CONSTITUTION.md and the compiled architecture;
• delivery/TEAM-OPERATING-CHARTER-2026-08-18.md;
• delivery/TEAM-RUNTIME-PROFILE.v1.json;
• delivery/EXECUTION-REVIEW-CONTROL-PLANE.v0.md;
• delivery/TEAM-OPERATING-CAPABILITY-REVIEW-2026-08-18.md;
• delivery/TEAM-RESUME-QUICKSTART-2026-08-18.md;
• delivery/W19-PROVEN-ORCHESTRATOR-CONFIGURATION-2026-08-15.md;
• delivery/W19-TEMPORAL-LAB-RUNBOOK-2026-08-15.md;
• services/symposium/src/symposium/w19_lab/;
• services/work-router/; and
• services/mcp-quality-fabric/.

If this document conflicts with an adopted higher-authority object, the higher-authority object
wins. Any accepted revision to the team operating contract must become a new immutable package and
external adoption record. Review of this candidate grants no current execution or effect authority.

3. Product outcome

Given an Operator objective and a changing set of agent sessions, the system shall:

1. preserve the exact objective, acceptance criteria, constraints, and non-goals;
2. decompose the objective into complete, dependency-aware, role-neutral work;
3. expose eligible work through role/capability queues;
4. permit exactly one eligible role-bound seat to acquire fenced custody;
5. start or resume durable workflow orchestration;
6. automatically execute the applicable validation and boundary controls;
7. require independent review and certification where policy requires them;
8. execute publication, deployment, trust, or destructive effects only under exact current grants;
9. preserve every material decision, evidence object, unknown, and recovery instruction;
10. survive agent, process, Temporal, Jira, and projection restarts without duplicating effects; and
11. close work only against reconciled evidence, with a freshness owner and re-entry trigger.

Success is a smooth, replayable chain of accountable outcomes. Message count, ticket movement, raw
commit count, or an agent appearing busy are not success measures.

4. Recursive operating model

4.1 Level 0: end-to-end outcome

The team delivers the Operator's outcome safely and efficiently even when work is parallel, roles
outnumber seats, sessions restart, agents are replaced, evidence conflicts, tests fail, handovers
race, or deployment must roll back.

4.2 Level 1: nine control loops

Loop A - intent to executable work

1. Operator or adopted Program Board process establishes objective, priority, acceptance, residual
risk, and non-goals.
2. Designer maps outcome -> capability -> current supply -> exact gap.
3. Designer produces role-neutral specifications and options.
4. Delivery Integrator ensures full parent-acceptance and critical-operation coverage.
5. Operations admits only adopted, dependency-ready, collision-free leaves.

Output: an admitted WorkAdmission; no preferred-person assignment.

Loop B - work distribution and custody

1. The work-control kernel exposes READY work by required role, capability, risk, and independence
class.
2. A ROLE_BOUND seat requests the highest-priority eligible row.
3. The kernel validates binding, incarnation, mutual exclusion, dependency, collision, admission,
expiry, effect ceiling, and current generation.
4. One transactional compare-and-swap wins.
5. The winner receives a WorkLease with a monotonically increasing fencing epoch.
6. The kernel emits an outbox event that starts or wakes the corresponding Temporal workflow.

Output: explicit work custody. Queue age may trigger vacancy/capacity escalation, but never silent
assignment to an effect role or an ineligible person.

Loop C - implementation and falsification

The Builder receives an exact packet containing the repository/base/tree, allowed paths, target,
contracts, non-goals, controls, stop rules, expiry, effect ceiling, and evidence requirements. The
Builder works within that boundary, heartbeats the lease, attacks its own change with a falsifying
negative control, and emits an exact CandidateReceipt.

Output: candidate commit/tree or content-addressed artifact plus builder evidence; not DONE.

Loop D - automatic validation

Candidate production starts a generated ValidationPlan that can compose:

• changed-surface and dependency analysis;
• format, lint, static type, and generated-drift checks;
• unit, integration, contract, schema, and parity tests;
• security, secret, tenancy, authorization, and provider-egress negatives;
• reproducible build, SBOM, signature, and artifact checks where required;
• Behavior-Driven Validation;
• deployment validation when a deployed target exists;
• restart, replay, rollback, and idempotency checks; and
• source -> artifact -> environment provenance.

Each runner emits a typed EvidenceReceipt. No validator self-selects PASS authority.

Loop E - independent review

The exact subject enters the review queues selected by the control pack. Architecture, adversarial,
security/authority, and independent test relationships remain separate where required. Reviewers do
not edit the reviewed subject. A correction creates a successor subject generation and reopens the
affected joins.

Output: exact-subject findings, conflict disclosure, verdict, limitations, and noncoverage.

Loop F - evidence certification

An unconflicted Evidence Certifier verifies acceptance-to-evidence coverage, actual invocation,
test denominator, source/artifact/environment identity, review independence, freshness, and honest
noncoverage.

Output: CERTIFIED, EVIDENCE_INCOMPLETE, or EVIDENCE_STALE; never effect authority.

Loop G - package, publish, deploy, and effects

The lifecycle keeps four independent transitions:

PACKAGE_RECEIPT
  != PUBLISH_RECEIPT
  != DEPLOY_RECEIPT
  != EFFECTIVE_RECEIPT

Release and Deployment roles consume an exact EffectGrant that binds executor, subject/artifact,
effect, target/environment, prestate, expiry, idempotency, rollback conditions, and approval
evidence. A role, PASS, queue claim, Jira status, or successful command never creates the grant.

Loop H - observe and learn

After an authorized effect, the system executes authenticated useful journeys, negative controls,
persistence/restart checks, serving-identity checks, and outcome observation. The actual workflow
role records a candidate scenario as GOOD, BAD, NEUTRAL, or UNKNOWN; an independent evaluator
validates it before promotion. Cortex may retain/retrieve the candidate but cannot evaluate or
authorize it.

Loop I - handover and restart

Every programme has a content-addressed Delivery Integration Brief. Every work item has a
content-addressed Handover Pack. Replacement sessions reconstruct from the adopted package,
external checkpoint, kernel, exact Git/artifact evidence, Jira projection, and channel provenance;
they do not inherit private chat as authority.

Output: two-sided receiver-accepted custody or explicit ORPHANED_UNVERIFIED.

4.3 Level 2: failure recursion

Every loop must define:

• its canonical input and output contracts;
• owner and non-owner boundaries;
• timeout and expiry behavior;
• retry and idempotency behavior;
• cancellation, failure, supersession, and orphan behavior;
• evidence required for progress;
• exact successor/re-entry phase after drift; and
• what remains safe when one dependency is unavailable.

One failed leaf, review, projection, or effect stops only its affected dependency region. Unrelated
GREEN work and independently admitted collision-free siblings continue.

5. Role, title, seat, and binding model

5.1 Vocabulary

• Title: human-readable presentation only.
• Role: reusable duty, eligibility, conflict, and permission contract.
• Seat: logical team capacity slot.
• Seat incarnation: one concrete live agent/session identity occupying a seat.
• Role eligibility: a seat may accept that role's duties and ceiling.
• Role binding: authenticated activation of one role for one incarnation/generation.
• Work custody: accepted work plus a fenced lease.
• Effect authority: a separate exact grant for a consequential action.

agent identity
  -> seat incarnation
      -> eligible roles
          -> active role binding
              -> permitted queue capabilities
                  -> fenced work lease
                      -> optional separate effect grant

5.2 Role responsibilities

The standing vocabulary is exactly the ten semantic roles in
delivery/TEAM-RUNTIME-PROFILE.v1.json. Test authoring, test execution, packaging, observation, and
projection are work functions, not additional standing roles. Their packets still name an active
eligible role binding, exact incarnation, conflict relationship, and required independence.

Execution functions map to the semantic roles as follows:

5.3 Delivery Integrator versus Operations Controller

The Delivery Integrator answers: "Are all necessary operations owned, coherent, and moving toward
the outcome?" The Operations Controller answers: "Is the work state mechanically valid,
collision-free, fenced, and projected correctly?"

The Integrator makes the programme successful through collaboration and must not become the default
builder. Operations maintains control-plane correctness and must not become the objective owner.

5.4 Secondary and dual roles

Exactly ten semantic roles are covered by eight seats in the current profile: eight primary roles
and two secondary-eligible roles (Release Executor and Evidence Certifier). Work functions in the
table above do not add seat-bearing semantic roles. Secondary eligibility is not active authority.

• A secondary role requires a new ROLE_BOUND before use.
• One event names exactly one active role binding.
• One incarnation never counts as two independent reviewers.
• Builder cannot review or certify its own subject.
• Reviewer cannot certify a subject it reviewed or produced evidence for.
• Delivery Integrator cannot dual with Builder, Deployment Engineer, or Release Executor.
• Incompatible role switch requires custody transfer or closure first.
• Delivery Integrator -> Builder requires a distinct bound successor and exact accepted control-room

handover before relinquishment.

6. Work-control kernel

6.1 Boundary

Adapt the existing work-router supply into a separately reviewed control kernel rather than create a
new ticketing product. The current router is a source donor, not the adopted charter kernel.

The target kernel owns only:

• admission consumption;
• role bindings and seat incarnations used for eligibility checks;
• claims, leases, heartbeats, and monotonically increasing fence epochs;
• work, handover, review, certification, and effect transition receipts;
• scoped holds, invalidation, and first-terminal-wins rules;
• append-only events and transactional outbox; and
• projection reconciliation state.

It does not own objective, priority, specification content, evidence content, correctness, or effect
authority.

6.2 Storage and mutation contract

Use a durable transactional store, initially PostgreSQL. PostgreSQL is selected for the production
pilot because the required proof is multi-process and multi-host one-winner custody with durable
transactions, row-version CAS, transactional outbox, and failover. SQLite remains acceptable for a
single-host laboratory or hermetic test, but it cannot establish the multi-host lease/fence claim and
must not be promoted as equivalent evidence.

Every mutation carries:

event_id
idempotency_key
actor_id
seat_incarnation_id
active_role_binding_id
work_id
subject_generation
expected_version
fencing_epoch
subject_digest
timestamp
evidence_refs

Required semantics:

• exactly one valid claim winner;
• stale fence rejected even when the former owner returns;
• same idempotency key + same canonical payload replays;
• same key + different payload conflicts;
• first valid terminal transition wins;
• lease expiry becomes ORPHANED_UNVERIFIED, never silent idle/reassignment;
• subject drift opens a successor generation without erasing predecessor evidence;
• holds remain scoped;
• outbox publication is retryable and does not create partial business truth; and
• Jira/channel/Temporal projection mismatch becomes PROJECTION_SPLIT_BRAIN.

canonical payload means RFC 8785 JSON Canonicalization Scheme bytes after strict schema parsing.
The parser rejects duplicate object keys, unknown fields, NaN/infinity, values outside the schema's
numeric bounds, and invalid UTF-8 before canonicalization. JCS does not normalize Unicode strings;
where a field permits normalization, its schema must state the exact normalization and the normalized
value becomes the durable value. Digests and idempotency comparison use canonical bytes, never the
caller's serialization, property order, whitespace, or transport encoding.

The kernel, not Temporal, enforces lifecycle joins. It rejects WORK_COMPLETED unless the current
subject generation has all required review joins, EVIDENCE_CERTIFIED, and every delivery/effect/
observation receipt required by that WorkAdmission. A source-only leaf can therefore complete without
a deployment receipt only when its admitted acceptance explicitly excludes deployment. Temporal may
request the transition; only the kernel validates and records it.

PROJECTION_SPLIT_BRAIN has a recovery contract rather than being a permanent alarm:

1. freeze new custody only in the affected projection/work scope;
2. retain kernel state as work truth and retain the divergent remote version as evidence;
3. have Operations run a deterministic compare using kernel generation, projector operation ID,
remote version, and write/readback receipt;
4. classify the difference as stale projection, authorized human proposal, unauthorized mutation,
or unresolved ambiguity;
5. apply a new idempotent projection operation only for the first two classes when policy permits;
6. require authenticated direction for a business-state change; and
7. clear the split only after readback matches a new reconciliation receipt. Never choose the more
convenient source or overwrite an unresolved human edit.

Custody, effect, lease, and completion registers are not CRDTs and do not use last-writer-wins.
Authoritative conflicts resolve through expected version, fence epoch, first-terminal-wins, and
successor generation. CRDTs may be used for non-authoritative collaborative annotations, provided
their merge result cannot bind roles, custody, completion, evidence, or effects.

7. Queue model

Do not create permanent queues named after individual agents. Use role/capability queues so agents
can be replaced, capacity can scale, and work does not become trapped behind one session.

The complete logical namespace is classified below. AGENT_PULL is eligible role-bound human/agent
work; MACHINE_ACTIVITY is a Temporal Task Queue or deterministic runner; KERNEL_RECOVERY is a
kernel-owned state with an explicitly accepted custodian; PROJECTION is an outbox consumer. An
owner is shown for every row so an automated queue cannot be mistaken for abandoned agent work.

The first controlled pilot activates only seven logical lanes: capability build, contract validation,
architecture review, adversarial review, evidence certification, packaging, and deployment-effect
wait. Design, integration, and Operations continue through the existing adopted process during that
pilot. Additional logical queues are activated only after measured contention, starvation, or control
separation justifies them; defining the namespace does not provision twenty workers or Task Queues.

Not every logical queue is a Temporal Task Queue:

• the kernel exposes human/agent work eligibility and owns the lease;
• a session/agent bridge delivers eligible packets and submits receipts;
• Temporal Task Queues execute durable automated activities;
• Jira shows the reconciled management projection; and
• the channel carries offers, acknowledgements, corrections, and provenance.

7.1 Elastic seats and adaptive capacity

Role/capability queues may scale horizontally by adding eligible seat incarnations, but capacity
pressure never creates role or effect authority. The system may detect pressure, recommend or
provision a session, load its role profile, and issue a role offer. ROLE_BOUND still requires an
authenticated issuer or an adopted bounded delegation policy; the new agent self-pulls through the
same one-winner CAS and fencing rules as every other seat.

The capacity controller evaluates the whole DAG rather than the largest local queue. It distinguishes
genuine READY work from raw, blocked, held, decision-waiting, collision-conflicted, or downstream-
constrained rows. It scales only when queue age/backlog growth, current utilization, downstream
headroom, collision rate, startup cost, role policy, and marginal throughput justify another seat.
Adding Builders while review, CI, a hot file, or one deployment environment is the constraint is not
scaling.

Scaling behavior is role-specific:

• Builders, independent reviewers, certifiers, and test runners can scale across separate leaves;
• Designers scale across distinct objectives, while one design generation retains one authoritative

owner/merge decision;

• Delivery Integrators scale by programme, never as competing writers for one programme brief;
• Operations Controllers use an active writer per shard plus standby/failover, not competing global

mutation authority; and

• release/deployment/effect capacity remains serialized by target and exact grants even when standby

executors exist.

The controller produces a typed CapacityRequest containing role/queue, pressure evidence, ready
count, oldest wait, arrival/completion rates, eligible/busy capacity, downstream headroom, collision
ratio, requested/max increment, permission/effect ceiling, duration, cost limit, authority reference,
and scale-down rule. Provisioning then emits SeatProvisionPlan -> RoleOffer -> ROLE_ACCEPTED ->
ROLE_BOUND -> WorkerRegistration -> QueueSnapshotDelivered. No step infers the next.

Enable capacity automation in three stages: advisory; automatic provisioning with externally
authorized binding; and bounded autonomous provisioning/binding for explicitly delegated low-risk
roles. Release, deployment, privileged operator, trust, secret, and destructive roles remain outside
generic autoscaling.

Scale-down stops new claims, drains or hands over current custody, proves that no work/effect/review/
handover custody remains, then relinquishes the role and retires or hibernates the incarnation while
preserving its Knowledge Pack. A quiet queue never permits termination of an agent with valid custody.
The full contract, decision function, failure modes, and canaries are specified in
delivery/team-role-queue-temporal-execution/ELASTIC-SEATS-AND-ADAPTIVE-CAPACITY.md.

A 2026-08-19 SQLite / Temporal-test-env PIN-READ walk (Grok occupying every kernel endpoint via
distinct incarnation IDs) confirmed that independence, one-winner CAS, and Temporal-not-truth already
match this section's scale unit. That walk is laboratory Increment 1B supply. It is not Increment 7,
not WP10, and not evidence that capacity can expand. The later-review pin is elastic-seats §18.

8. Temporal orchestration

8.1 Workflow identity

Design decision TD-001: use Temporal for the controlled internal pilot. This records the
Operator's stated direction to exercise Temporal internally; it does not make Temporal constitutional
authority or approve production rollout. A database scheduler alone is weaker for durable timers,
long observation windows, replay, child joins, worker versioning, and cancellation. Jira polling is a
projection loop, not orchestration. NATS is useful transport but does not supply workflow history.
Temporal is therefore the preferred orchestrator provided the runtime-independent kernel contracts,
replay tests, outage behavior, and rollback canaries pass. Failure of those gates returns the design
to an alternative evaluation rather than weakening the contracts.

Create a new production-shaped workflow identity rather than renaming or silently promoting the
current W19 demo workflow:

TeamDeliveryWorkflow
workflow_id = team-delivery/<work-id>/<generation>

Reuse independently verified W19 schemas, activity adapters, tests, and recovery lessons as donors.
Do not discard that investment, but do not treat a hardened laboratory adapter as production by
inheritance. The production workflow consumes the same versioned contracts through an explicit
compatibility adapter and kernel-validated events. W19 remains runnable as a lab/shadow harness until
the controlled pilot demonstrates equivalence.

Input references immutable and kernel-owned facts: work/generation, admission event/digest,
packet/bundle/policy/control-pack digests, kernel generation, required role/independence class,
effect ceiling, and expiry.

8.2 Workflow chain

verify admission
  -> wait for fenced claim
  -> dispatch/observe implementation
  -> wait for exact CandidateReceipt
  -> run Validation child workflow
  -> request required independent reviews
  -> join review receipts
  -> request evidence certification
  -> package
  -> wait for exact EffectGrant if needed
  -> publish/deploy
  -> observe/recover
  -> evaluate/learn
  -> close with recheck or open successor iteration

8.3 Signals and child workflows

Temporal consumes only kernel-validated event references/digests such as WorkClaimed,
LeaseHeartbeat, CandidateProduced, EvidenceRecorded, ReviewRecorded,
CertificationRecorded, EffectGranted, HandoverOffered, HandoverAccepted, WorkCancelled,
and SubjectSuperseded. A raw agent signal cannot bind a role, claim work, or grant an effect.

Use child workflows for Validation, Independent Review, Evidence Certification,
Package/Publication/Deployment, Observation/Recovery, and Handover/Orphan Recovery.

Temporal is valuable for deadlines, expiry, retry/backoff, long-lived waits, observation windows,
freshness triggers, and deterministic replay. It must not own objective, priority, role authority,
work truth, lease epochs, Jira truth, correctness, evidence content, effect grants, or learning
promotion.

At every signal/update boundary, a Temporal adapter dereferences the event ID from the kernel,
recomputes or checks its canonical digest, verifies work/generation/version/fence applicability, and
only then records the reference in workflow history. A signal's self-assertion that it was validated
is never sufficient.

9. State and evidence model

Do not collapse the lifecycle into one global status.

ROLE: offered -> accepted -> bound -> succession/relinquished/vacated/expired/revoked
WORK: proposed -> specified -> ready -> accepted -> claimed -> in_progress -> completed
      exceptions: held/failed/cancelled/superseded/expired/orphaned_unverified
REVIEW: requested -> in_progress -> pass/needs_changes/constitutional_block
EVIDENCE: pending -> collecting -> complete -> certified/incomplete/stale
EFFECT: proposed -> granted -> executing -> succeeded/failed -> rolled_back/reapplied

Always report SOURCE, BUILT, PUBLISHED, DEPLOYED, EFFECTIVE, DEMO, and APP
independently.

10. Automated BDV, contract, and boundary validation

Use the explicit gate ID behavior-driven-validation/v1. BDV is Behavior-Driven Validation and is
supplemental. Deterministic test execution, contract/schema/parity checks, security invariants,
provenance, and deployment/useful-journey evidence remain authoritative within their denominators.
No default score, missing tool, model assertion, or failed validator becomes PASS.

Every ValidationPlan binds exact source/artifact, execution bundle, role profile, policy set,
adapter registry, control packs, changed/dependency surface, risk, environment/toolchain, test
denominator source, and required scenarios.

Every EvidenceReceipt records:

receipt_id, validation_plan_digest, subject_commit, subject_tree, artifact_digest,
runner_identity, runner_role, toolchain_digest, command, collected_test_ids_digest,
cohort_total, selected, deselected, passed, failed, skipped, xfailed, errors, unknown,
started_at, completed_at, exit_status, stdout/stderr artifact refs,
establishes, does_not_establish, untested_inference

Quality Fabric may execute checks and return evidence, but its verdict cannot grant work, review,
certification, publication, deployment, or runtime authority.

11. Knowledge and handover protocol

11.1 Delivery Integration Brief

The standing non-coding Delivery Integrator maintains a content-addressed brief containing objective
and non-goals, critical path, parent coverage, custody, dependencies, decisions, capacity, reviewer
margin, handovers, vacancies, risks, evidence conflicts, delivery axes, freshness, and exact next
actions/accountable functions.

11.2 Work Handover Pack

Every handover binds handover/schema/idempotency identities, revision/digest, issue/expiry,
work/generation/subject, producer seat-role-session/lease/fence, intended receiver, completed and
remaining acceptance, decisions, commands, evidence, failures/unknowns, dirty/local-only state, safe
continuation, cleanup/rollback, durable resume, and checkpoint.

HANDOVER_OFFERED
  -> receiver verifies exact pack/subject/generation
  -> HANDOVER_ACCEPTED
  -> atomic custody CAS
  -> predecessor lease closes
  -> receiver receives a new fence epoch

Bare producer release is rejected. Producer disappearance produces ORPHANED_UNVERIFIED; recoverable
dirty, untracked, local-only, nested, LFS, alternate/promisor, process, and secret-sensitive state is
preserved in restricted durable custody before reassignment. Cortex may index packs for retrieval;
Git/artifacts and the kernel remain authoritative.

Secret custody is reference-first and purgeable. General handovers, evidence, logs, Jira, channels,
and Cortex store only a typed secret incident/reference, location class, exposure window, and required
rotation action--never the secret value. If byte preservation is legally or operationally required,
the value goes only to an approved encrypted restricted store with named custodians, retention/expiry,
access log, deletion method, and a separately authorized purge/rotation receipt. A store that cannot
honor purge must not receive secret values. Sanitized work can be preserved independently of the
restricted secret object.

12. One-action team start and restart

Extend the current resume capability as a two-step plan/apply operation:

team resume --profile <profile-id> --plan
team resume --profile <profile-id> --live --plan-digest <digest> --confirm

--plan is the default and has zero external writes. It reports the exact package/profile/checkpoint,
incarnations, role bindings to reuse, workers to reconnect, workflows to wake, leases/handovers/
orphans to reconcile, projections to inspect, collisions, blocks, and the proposed action digest.
--live rejects a missing, stale, changed, or expired plan digest and requires explicit confirmation.

The apply step shall verify the operating package/adoption/checkpoint/objective/work graph, load the seat-role
profile, enumerate/exclude incarnations, detect collisions, resolve but not mint role bindings,
reconcile leases/handovers/holds/reviews/effects/orphans, reconnect gateways/workers, resume workflows,
deliver role-specific snapshots, collect READY/NEEDS_CORRECTION/BLOCKED, and publish one verified
rollcall/queue-health report. The button never grants roles, work, review, merge, deployment, trust,
or other effects.

Supporting operations are team onboard-seat, team bind-role, team add-secondary-role,
team switch-role, team replace-seat, team retire-seat, team handover, team resume, and
team status.

13. Jira, dashboard, and channel projection

Use Portfolio -> Outcome -> Critical Operation -> Delivery Packet -> Build/Test/Review/Effect.
Kernel -> Jira is the authoritative projection direction. Human edits enter as evidence, proposals,
or separately authenticated direction through another adapter. Raw status never advances kernel
truth.

The Jira projector requires deterministic operation ID, expected-version conflict check, idempotent
replay, write/readback, resumable create saga, human-edit detection, and
PROJECTION_SPLIT_BRAIN on mismatch.

The dashboard shows role queues, ready/claimed/held/orphan counts, eligible seats/vacancies, oldest
wait, critical path, lease/fence/expiry, validation/review/certification joins, delivery axes,
handover/decision age, next action/accountable function, and projection freshness.

The channel carries durable offers, acknowledgements, corrections, findings, review requests, and
handovers. RECEIVED remains transport only; sender label proves no role, custody, correctness,
certification, or effect authority.

13.1 Existing-supply migration and rollback

The work-router/pipeline engine, W19 laboratory, Jira automation, and channel remain in service until
the replacement slice proves equivalence. Migration is side-by-side and one work class at a time:

1. inventory each existing writer, transition, retry, projection, and recovery behavior;
2. map old identifiers/states to new contracts without inventing evidence;
3. run the new kernel/projectors in read-only shadow mode and compare outputs;
4. select one noncritical work class and one authoritative writer by an immutable migration record;
5. prohibit dual authoritative writes; legacy mutations for that class become proposals or are
rejected;
6. retain a reversible routing switch and exportable reconciliation snapshot;
7. prove claims, handovers, restarts, Jira reconciliation, and rollback through canaries; and
8. retire the legacy claim path only after cold-session and rollback evidence passes.

Rollback stops new admissions to the pilot class, lets safe in-flight activities quiesce or cancel,
preserves kernel/event/outbox history, reconciles accepted custody, restores the previous routing
record, and verifies that no effect was duplicated. It never rewrites history or silently maps an
unknown new state to a legacy DONE.

14. Failure and recovery matrix

15. Acceptance and falsification suite

15.1 Seat, role, lease, and custody

• onboard/replace/switch/retire seats without losing valid coverage;
• reject incompatible dual binding and false reviewer independence;
• reject Delivery Integrator -> Builder without successor handover;
• exclude VACATED from liveness/capacity/trust;
• 50-way/two-host claim race has one winner;
• reject stale epochs, including returning same owner;
• deterministic heartbeat/expiry race;
• expiry creates orphan, not idle;
• scoped hold leaves siblings runnable; and
• restore dirty/local-only state byte-identically without leaking secrets.

15.2 Temporal, validation, and evidence

• kill after every workflow transition;
• retry after remote success/lost response;
• replay after worker upgrade;
• duplicate same event is idempotent; changed payload conflicts;
• one child failure does not corrupt siblings;
• no activity infers an effect grant;
• actual collected test IDs must match claimed denominator;
• selected/deselected/skipped/xfailed/error/unknown cannot disappear;
• unavailable validator cannot PASS;
• subject drift invalidates successor readiness;
• unsupported conclusion from a true measurement is refused; and
• tampered source/artifact/environment identity fails closed.

15.3 Review, handover, and effects

• builder cannot review/certify own subject;
• reviewer cannot certify a subject it reviewed;
• correction requires a fresh exact review;
• unresolved affecting finding blocks the applicable join;
• two receivers racing one handover yield one valid CAS;
• stale offer/epoch/generation and producer early release are rejected;
• receiver crash after acceptance preserves custody;
• fresh session resumes without private chat;
• same exact effect replays once; changed effect conflicts;
• artifact/config mismatch blocks deployment; and
• package, deployment, and effectiveness never infer one another.

16. Metrics

Measure ready-to-claim, claim-to-candidate, candidate-to-validation, review/certification latency,
critical-path movement, eligible-work coverage, queue starvation/oldest wait, blocker/decision/
handover age, collision/stale-fence/orphan/false-ready/false-done rates, reviewer margin, validation
denominator completeness, evidence freshness, cold-session reconstruction, useful post-deploy
outcome, capacity-request accuracy, provision-to-ready time, marginal throughput per added seat,
scale-up/down churn, downstream saturation, and Delivery Integrator implementation/effect violations
(target zero).

Do not optimize message count, raw ticket transitions, or unaudited commit/deployment count.

The controlled pilot records baselines before setting production SLOs. Its initial falsification
targets are:

These are pilot acceptance targets, not measured current performance or production promises.

17. Implementation sequence

This is not a big-bang programme. Each increment has a separately useful, reversible output:

The recommended first product leaf is a safe, read-only, server-scoped Cortex MCP capability plus its
dashboard representation, not operator pin creation, protected purge, trust mutation, or autonomous
deployment. It exercises design, identity, API/MCP parity, build, validation, review, certification,
packaging, deployment wait, and observation while keeping the effect and data-mutation blast radius
small. The worked flow and bottlenecks are documented in
delivery/team-role-queue-temporal-execution/END-TO-END-SCENARIO-AND-BOTTLENECKS.md.

Increment 0 - freeze contracts

Author/review strict SeatIncarnation, RoleBinding, WorkAdmission, WorkLease, WorkEvent,
ValidationPlan, EvidenceReceipt, ReviewReceipt, CertificationReceipt, EffectGrant/Receipt,
HandoverOffer/Disposition, KnowledgePack, and ProjectionOperation schemas with closed-shape,
transition, compatibility, subject-drift, duplicate-key, and authority-negative tests.

Increment 1 - work-control kernel

Build PostgreSQL admission consumption, leases/fences, events, idempotency, scoped holds,
handover/orphan state, review/effect transitions, and transactional outbox.

Before enabling mutation, expose a read-only shadow projection of existing queue, eligibility,
vacancy, collision, and age facts. Compare it with current Jira/work-router/channel observations and
publish mismatch receipts. Then enable custody only in a disposable pilot namespace.

Increment 2 - Temporal source-change pilot

Implement one TeamDeliveryWorkflow for one noncritical source-change class with Capability Builder,
Validation/Test Runner, Architecture Reviewer, Evidence Certifier, and manual Operator effect grant.
Activate only the seven pilot lanes named in section 7. Do not enable autonomous publication or
deployment.

Increment 3 - validation composition

Wire deterministic controls, Quality Fabric, explicit BDV, durable evidence, denominator capture,
and evidence certification.

Increment 4 - projections

Implement Jira projector/reconciler, channel notifications, queue dashboard, and split-brain
detection. Jira remains projection, not authority.

Increment 5 - resume and seat lifecycle

Wire resume/onboard/replace/switch/retire to external role bindings, kernel state, session gateways,
Temporal history, and Knowledge Packs.

Increment 6 - controlled pilot

Exercise one noncritical source-change outcome through specify -> admit -> self-pull -> build ->
validate -> review -> certify -> package -> manually authorized effect -> observe -> handover ->
restart -> close. Enable broader automation only after replay, failure, security, and useful-outcome
canaries pass.

Increment 7 - elastic-seat pilot

After the controlled workflow pilot is stable, add advisory capacity decisions for one Builder queue.
Prove that the controller distinguishes capacity shortage from decisions, collisions, downstream
congestion, and false-empty queues. Then provision one ephemeral low-risk Builder seat under an exact
bounded delegation, measure marginal throughput, drain it without losing custody, and repeat for an
independent review queue. Do not autoscale effect roles.

The 2026-08-19 PIN-READ laboratory walk does not start this increment. It only shows that a later
ephemeral Builder would enter through the same CAS and independence gates already used by ordinary
seats (elastic-seats §18).

18. Current-state truth

The shared worktree currently contains in-progress modifications to Temporal adapters and seat
lifecycle tests. They are useful implementation supply but are not credited here as reviewed,
landed, deployed, or effective. Freeze them to an exact subject, collision check, test, independently
review, and integrate through the normal lifecycle.

19. Required review challenges

1. Does any component become a hidden objective, work, role, review, evidence, or effect authority?
2. Are Delivery Integration and Operations distinct, non-coding, and appropriately bounded?
3. Are queues capability-based and replaceable without trapping work behind one agent?
4. Can a stale/malicious incarnation mutate work after reassignment?
5. Can Temporal replay duplicate effects or trust unverified signals?
6. Does validation disclose its denominator and keep BDV supplemental?
7. Are testing, review, certification, publication, deployment, and effectiveness independent?
8. Can a replacement reconstruct every critical fact without private chat?
9. Does orphan recovery preserve dirty/local-only/secret-sensitive state before reassignment?
10. Is Jira/channel/dashboard drift detected without choosing a convenient source?
11. Does one-click resume help without minting authority?
12. Is the Increment 2 pilot small enough to falsify the architecture before rollout?

20. Review disposition

The initial channel review at sequences 4578-4595 returned architecture, adversarial, deployment,
builder, and stability findings. R1 accepts and incorporates the actionable findings on role count,
canonical payloads, completion ordering, queue ownership/sizing, Temporal selection and verification,
incremental value, W19/legacy migration, split-brain recovery, secret custody, plan-first resume,
PostgreSQL rationale, CRDT boundaries, scenario walkthroughs, and pilot metrics. The exact disposition
of every finding is in REVIEW-RECONCILIATION.md.

R1 was RECONCILED_DESIGN_CANDIDATE_READY_FOR_IMMUTABLE_REVIEW. R2 adds the elastic-capacity design
as a successor exact subject and is source-final for this design iteration, but it is not operationally
final. The package must be committed or otherwise durably published as one immutable exact subject,
all component digests must be anchored, and independent reviewers must rebind to R2. Findings remain
input, not self-applying amendments. Any accepted R2 correction creates another successor; adoption,
implementation, role binding, work custody, Jira mutation, Temporal startup, publication, deployment,
and effects remain separate actions and authorities.