glm-5.2
df5d04af1d
Establishes the tasks/architecture/ blocker-task half of the Safe Exit protocol. Each deferred OQ now has an external-trigger tracker task representing its unblocking condition, and the OQ's Blocked on field names the tracker task ID — closing the gap where the deferral field existed but the task-graph half was unenforced. Changes: - Add 6 external-trigger tracker tasks for the deferred OQs (OQ-09, 10, 32, 41, 44, 46) under tasks/architecture/, tagged [external-trigger, deferred-oq] - Add structured Blocked on field to OQ-09 and OQ-10 (previously used legacy 'deferred' status with the reason in the Resolution prose); index now surfaces all 6 deferred OQs with concrete conditions, no placeholders - Document the architecture-task level mapping (level: implementation for ADRs/specs, decomposition for spec-to-ADR breakdown, planning for backlog seeding, research/review direct fits) and the deferred-OQ blocker-task pattern in docs/sdd_process.md - Mark architecture/safe-exit-blocker-task-mechanism and architecture/oq-09-10-blocking-conditions completed (implemented by this pass) - Fix 4 pre-existing ADR-050 implementation tasks: status: done → completed (taskgraph enum is 'completed', not 'done') — taskgraph validate now passes for all 100 tasks
2.1 KiB
id, name, status, depends_on, scope, risk, impact, level, tags
| id | name | status | depends_on | scope | risk | impact | level | tags | ||
|---|---|---|---|---|---|---|---|---|---|---|
| architecture/oq-32-multihop-use-case | External trigger — a concrete multi-hop federation use case | pending | single | trivial | component | research |
|
Description
External-trigger tracker for OQ-32
(Multi-Hop Federation). This is not actionable work — it tracks whether a
concrete use case for multi-hop federation has arrived. When it does, mark this
task completed and the OQ moves from deferred(scope) to open.
Trigger condition
A concrete deployment or use case that requires transitive op discovery across more than one hop — i.e., worker A needs to reach worker B's ops through the head, where the head is not explicitly re-exporting them. The one-hop model (head→worker, runner→hub) covers all current use cases.
What unblocking looks like
When a use case arrives:
- Mark this task
status: completed. - Move OQ-32
from
deferred(scope)toopen(update the Status field + theopen-questions.mdindex tables + Deferred/Blocked section). - Create an architecture task to write the multi-hop federation ADR — the
peer-keyed overlay model extends to multi-hop without redesign (ADR-029 §3.7),
but path-finding (which peer reaches which op transitively) is where the
design work lives. A graph library (petgraph) may pay off for multi-hop; for
one-hop, a nested
HashMap<PeerId, HashMap<String, ...>>suffices.
Why this is a task, not just an OQ field
The OQ's Blocked on: field in open-questions.md is the human-readable
visibility surface ("what's parked and why"). This task is the machine-readable
half: it lives in the task graph so taskgraph tools can reason about it, and
so downstream work that depends on multi-hop being resolved can declare
depends_on: [architecture/oq-32-multihop-use-case].
Verification
This task is "completed" when a concrete multi-hop use case is documented
(e.g., in a research finding or deployment note) and OQ-32 has been moved to
open.