[schickling-assistant]

Stacked on #5993 (base: its branch). Depends on #5993. Part of #867 / #5019 PR3-C. This PR must land before external-grant issuance is enabled (condition recorded in #5993).

Problem

In #5993, attach_claim attaches a newly authenticated assistant-grant base or transition to every authenticated opposite record of the same subject, origin and actor, inside one maintenance unit. An admitted member can replicate many valid signed bases and transitions for one subject. One unit then expands into a bases-by-transitions cross product while the writer is held. The 64-unit / 100 ms slice budget cannot interrupt that loop. (Security review of #5993; the loop exists since 5f0ada37.)

Goal (FPL decision)

A durable, resumable attachment task, charged per candidate pair against the slice budget, with the subject fenced until the task completes. No per-subject history cap.

Decisions

• Attachment tasks. Authentication enqueues at most two partitions per claim (opposite kind), in the same transaction. Each maintenance unit visits one candidate through an exact issuer/kind keyset index, below a fixed high-water mark, and re-reads both authenticated endpoints. Invalid candidates also cost one unit. A late opposite arrival creates its own task. Demotion and trim cancel the owner's tasks. An isolated first local base with no opposite history stays immediately usable (self-row only).
• Fence. subject_pending covers attachment tasks and conflict witnesses. A restrictive partial attachment keeps the previous effective row as a witness until the subject has no tasks.
• One scheduler. Demotion runs first. All other work uses one durable round-robin turn over eight queues: dirty authentication, proof recheck, proof invalidation, membership retraction, coverage addition, attachment, witness cleanup, initial history. Each occupied visit costs one unit; an empty queue costs one indexed probe. This replaces the half-slice reservation from fix(external-grants): suspend fleet-wide mixed-profile grant conflicts (#5019 PR3-C) #5993.
• Owner fairness. Each of the seven work queues orders owners by a queue-local, monotone admission sequence (trigger-maintained registry), with a durable cursor and a fixed frontier per round. Owner order no longer depends on content-hash claim IDs, which an attacker can choose. An owner that is in the queue at the start of a round is served in that round, whatever its ID.
• Migration. Projection version stays 1, because fix(external-grants): suspend fleet-wide mixed-profile grant conflicts (#5019 PR3-C) #5993 has not been released. Installation adds empty task, witness and registry tables and registers the already-queued owners once; it does not rescan raw history.

Verification

• Tests added: Cartesian product within the slice budget in both arrival orders (local and verified); Duration::ZERO one-unit termination; cursor and witness survive a file reopen; invalid candidates are charged; late opposite arrival; trim during a task; fence lift for a completed subject next to an unrelated continuous backlog; ineligible-witness prefix is bounded; every non-empty queue is served within one round; attachment and proof-recheck owners finish while lower-ID and between-ID arrivals continue.
• Local run: NOT RUN yet. The release smallclaims --lib assistant_grant_authority run is queued on a shared host (disk admission). Results will be posted here. Hosted CI runs only after this PR's base becomes main.
• Reviews (static; tests not run by reviewers): reviewer GO and security-reviewer GO at 22b947e4. They found three problems in earlier commits, and later commits fixed them: global witness cleanup starvation (719dd9d2), uncharged ineligible-witness probes and reservations that starved other queues (4d26734b), and hash-ordered owner starvation (22b947e4). The implementer and the two reviewers are GPT family. The Claude-family review follows in a comment.

Complexity

The change adds a task table, a witness table, an owner registry and one scheduler. Without them, the slice budget cannot bound attachment work, and the queues cannot serve owners fairly. About 640 of the 1217 changed lines are tests.

Concerns

• Total work and storage stay O(B×T) for a subject with B bases and T transitions. Only the per-transaction work is bounded.
• Demotion keeps strict priority over all other queues.
• This PR is larger than the ~300-line guideline. The scheduler and the attachment tasks depend on each other, so splitting them would produce a PR with an unbounded or unfair intermediate state.

Friction & bottlenecks

The local verification of #5993 and of this PR waited hours for shared build capacity. Some runs stopped on host memory or disk floors.

References

Depends on #5993. See #867, #5019.

Posted on behalf of @schickling

field	value
agent_identity	agent/dotfiles/st-delegation-2
session	01a0bfeb
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.12.5
agent_runtime	OMP 18.12.5
agent_model	anthropic/claude-opus-5-5
worktree	867-attachment-budget/2026-11-10-867-attachment-budget

[schickling-assistant]

Smalltalk authority engineer (agent/dotfiles/st-delegation-2, Claude-family review) of 479aba0b..22b947e4909b5efb1ce1802ce60ec57a61fd18bc (4 signed commits; implementer GPT family). Scope of the review: install_queue_owners, queue_owner, the eight-queue dispatch, attachment and witness dispatch, and the new tests.

• Registry triggers: the insert trigger checks NOT EXISTS before it assigns a sequence, so a re-enqueue keeps the original sequence, also under an outer UPSERT. The delete trigger removes exactly the matching (queue, owner, subowner) row. Triggers run in the caller transaction, so the registry rolls back together with the work row.
• queue_owner: a keyset seek on UNIQUE(queue,sequence) inside (cursor, frontier]. When the round is exhausted, the frontier moves to the current counter and the seek starts again from 0. The cursor persists before the unit runs, so an unfinished owner resumes in the next round and cannot hold the queue. Arrivals after the frontier wait for the next round, whatever their claim ID. This resolves the hash-ordering starvation.
• Bounds: one owner and one candidate per unit; at most eight queue probes for an empty dispatch; demotion runs first. I found no uncharged history-sized scan.
• Migration: one-time registration of the already-queued owners only. This is safe because projection version 1 has not shipped.
  Review: GO for the source. A release test run is still required; the run is queued and the results will be posted here.

Posted on behalf of @schickling

field	value
agent_identity	agent/dotfiles/st-delegation-2
session	01a0bfeb
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.12.5
agent_runtime	OMP 18.12.5
agent_model	anthropic/claude-opus-5-5
worktree	smalltalk/main