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.5 KiB
id, name, status, depends_on, scope, risk, impact, level, tags
| id | name | status | depends_on | scope | risk | impact | level | tags | |
|---|---|---|---|---|---|---|---|---|---|
| architecture/oq-09-10-blocking-conditions | Add explicit Blocked on conditions to OQ-09 (WASM) and OQ-10 (Git Adapter) | completed | narrow | low | component | decomposition |
|
Description
During the open-questions.md decompose (July 2026), I found that OQ-09 (WASM
Target Boundaries) and OQ-10 (Git Adapter Scope) use the legacy deferred
status without a structured Blocked on: field. They predate the formalized
deferred(scope) + blocking-condition pattern established by ADR-009's Safe
Exit protocol.
The four newer deferred OQs (OQ-32, OQ-41, OQ-44, OQ-46) all carry an explicit
Blocked on: condition. OQ-09 and OQ-10 do not — their deferral reason lives
in the Resolution prose, not in a structured field.
This matters because the new open-questions.md index has a "Deferred / Blocked"
section that surfaces Blocked on: inline as the safe-exit visibility surface.
OQ-09 and OQ-10 currently render as "(no explicit blocking condition recorded
— see full file)" in that section, which weakens the visibility guarantee.
Work
Either:
- Add a
Blocked on:field to each (e.g., OQ-09: "blocked on: a concrete server-side WASM use case — currently a design constraint, not a deliverable"; OQ-10: "blocked on: speccing alknet-git — resolve when that crate is specified, not deferred past it"), or - Reframe them as
deferred(scope)if the originaldeferredstatus was imprecise, and confirm the blocking condition from the Resolution text.
The decision content stays unchanged — this is a metadata-structure fix, not a re-resolution.
Summary
Completed alongside architecture/safe-exit-blocker-task-mechanism. Added a
structured Blocked on: field to both OQ-09 and OQ-10 in their per-OQ files,
each pointing at its new external-trigger tracker task
(architecture/oq-09-wasm-server-use-case,
architecture/oq-10-git-adapter-spec). Kept the legacy deferred status
rather than reframing to deferred(scope) — the distinction is no longer
load-bearing now that both have explicit blocking conditions and tracker
tasks. The open-questions.md Deferred/Blocked section now surfaces all six
deferred OQs with concrete conditions inline — no placeholders remain.
Verification
The "Deferred / Blocked" section of docs/architecture/open-questions.md
shows a concrete blocking condition for OQ-09 and OQ-10 instead of the "no
explicit blocking condition recorded" placeholder.