saga handler allowlist migration slice: cd33d8f482f8c26b

[loning]

saga handler allowlist migration slice

Machine-filed ratchet slice issue.

Ratchet

• parent_issue: saga-handler migration (G10): shrink migration/saga-handler.allowlist (41→0) via sliced children, not a mega-PR #979
• ratchet: saga-handler
• migration_kind: allowlist
• allowlist_path: migration/saga-handler.allowlist
• current_count: 12
• target_count: 0
• slice_size: 3
• selected_count: 3
• sites_fingerprint: cd33d8f482f8c26b
• dedup_key: saga-handler/slice/cd33d8f482f8c26b

Reference Shape

Use the existing std.saga.department(spec, handlers) shape from migrated departments.

Exact Sites

• packages/github-devloop/departments/rollup_merge/main.lua:19 (free_form_pipeline)
• packages/github-devloop/departments/rollup_scan/main.lua:114 (free_form_pipeline)
• packages/github-devloop/departments/substrate_ref_scan/main.lua:12 (free_form_pipeline)

Acceptance Criteria

• Migrate only the exact sites listed above.
• Remove only those migrated entries from migration/saga-handler.allowlist.
• If every listed site is already migrated and every corresponding allowlist entry is already absent, treat the slice as already converged and make no source changes.
• The allowlist count decreases only for listed entries still present in migration/saga-handler.allowlist and may be unchanged only when the slice is already converged.
• Behavior is preserved.
• scripts/run.sh test exits 0.
• No broad cleanup, opportunistic refactors, or unrelated migration work.

[loning]

github-devloop thinking: consensus started

[loning]

github-devloop convergence round 0 - no three-angle consensus; narrowing

Narrowed question: Does #1193 still represent active work for saga-handler/slice/cd33d8f482f8c26b, or is there concrete stale/cancelled/invalid evidence or an explicit duplicate-run waiver that justifies #1194?

Angle stances:

• minimal: abstain — Established practice for ratcheted migrations is WIP-limited, idempotent slice execution keyed by a stable dedup identifier; under the minimal angle, this issue is not the smallest coherent path because the board already shows saga handler allowlist migration slice: cd33d8f482f8c26b #1193 in fkst-dev:implementing with the same title/fingerprint cd33d8f482f8c26b and the issue body repeats the same dedup_key saga-handler/slice/cd33d8f482f8c26b, so approving saga handler allowlist migration slice: cd33d8f482f8c26b #1194 would authorize duplicate concurrent work unless there is concrete evidence that saga handler allowlist migration slice: cd33d8f482f8c26b #1193 is stale/abandoned/invalid or an explicit duplicate-run waiver.
• structural: abstain — Established practice for migration work queues is single source-of-truth plus idempotent deduplication: one active work item per stable dedup_key, with slices advancing the allowlist monotonically. This proposal’s local shape, std.saga.department(spec, handlers), is structurally acceptable, but saga handler allowlist migration slice: cd33d8f482f8c26b #1194 duplicates active saga handler allowlist migration slice: cd33d8f482f8c26b #1193 with the same fingerprint and dedup_key saga-handler/slice/cd33d8f482f8c26b, while recent history already includes the same-class duplicate-slice failure (Migration slicer creates cross-instance DUPLICATE slices (own-bot-marker dedup fails across bots) — make slice existence author-agnostic via entry-key + Git-ref CAS ledger + canonicality gate #1170). Without an explicit waiver or evidence that saga handler allowlist migration slice: cd33d8f482f8c26b #1193 is stale/cancelled, approving another identical sli
• delete: abstain — Established practice for migration ratchets and work queues is idempotent, uniquely keyed work with one live surface per deterministic key; this issue does not prove a new surface is necessary because saga handler allowlist migration slice: cd33d8f482f8c26b #1193 is already fkst-dev:implementing for the same saga handler allowlist migration slice: cd33d8f482f8c26b and the same dedup_key saga-handler/slice/cd33d8f482f8c26b, while the recurrence history shows repeated same-class duplicate slices, so the delete-angle concern is that saga handler allowlist migration slice: cd33d8f482f8c26b #1194 should be collapsed into the existing implementing item or treated as a no-op until the slicer/enqueuer enf

⟦AI:FKST⟧

[loning]

github-devloop decision: approve
Three-angle verdicts: minimal=abstain structural=abstain delete=approve

minimal:
Established practice for idempotent work queues is single-flight/deduplication by stable key; under the minimal angle, #1194 is unjustified extra scope because #1193 is still marked fkst-dev:implementing for the same saga-handler/slice/cd33d8f482f8c26b, with no concrete stale/cancelled/invalid evidence or explicit duplicate-run waiver in the provided context; approval would require proof #1193 is no longer active or a scoped waiver explaining why parallel duplicate execution is necessary.

structural:
Under standard idempotent work-queue/saga practice, a dedup_key must have one active source of truth until stale, cancelled, or explicitly waived; the manifest shows #1193 is still fkst-dev:implementing for saga-handler/slice/cd33d8f482f8c26b, while #1194 repeats the same slice with no concrete stale/cancelled evidence or duplicate-run waiver, so structurally this risks split ownership and duplicate mutation of migration/saga-handler.allowlist rather than preserving reliable data flow.

delete:
Established practice for idempotent work queues is single-flight/deduplication by a stable idempotency key: only one active work item should exist for saga-handler/slice/cd33d8f482f8c26b unless the prior item is proven stale, cancelled, invalid, or explicitly waived. The manifest shows #1193 is still fkst-dev:implementing for the same title, fingerprint, and dedup_key, while #1194 adds only a new thinking duplicate with no stale/cancelled/invalid evidence and no duplicate-run waiver; recurrence evidence also shows this is a repeated duplicate-slice class, so the correct delete-angle outcome is to remove/no-op #1194 and require a class-level deterministic dedup fix rather than preserve the extra surface.

⟦AI:FKST⟧

[loning]

github-devloop implementation worktree ready

Worktree: /Users/auric/.fkst-dogfood/dogfood-rt-packages.1781871235/worktrees/devloop-ChronoAIProject-fkst-packages-1194-1022129057
Branch: devloop/issue/ChronoAIProject/fkst-packages/1194/ready-consensus-github-devloop-issue-ChronoAIProject-fkst-packages-1194-2026-06-19T12-14-16Z-loop-1-1022129057
Base branch: integration
Base head: 3e05539

[loning]

github-devloop implementation output published

Worktree: /Users/auric/.fkst-dogfood/dogfood-rt-packages.1781871235/worktrees/devloop-ChronoAIProject-fkst-packages-1194-1022129057
Branch: devloop/issue/ChronoAIProject/fkst-packages/1194/ready-consensus-github-devloop-issue-ChronoAIProject-fkst-packages-1194-2026-06-19T12-14-16Z-loop-1-1022129057
Head: 5720733
Base branch: integration
Base head: 3e05539