Why this needed a decision, not just a reminder
docs/handoffs/HANDOFF_standalone-3fd9_projector-gate-findings-closed_2026-08-16_7c19.md
named nix2cf as "in the operator's approved scope for two sessions now and
still never touched," framed as something at risk of being forgotten a
third time. That framing undersold what's actually going on.
architecture-DEFINITIVE-v3.md's own build-order table (line ~946) is
explicit:
| Step |
What |
| 1 |
macOS services adapter. Dry-run default. No nix-darwin. |
| 2 |
Android under the Site Model; Termux types; agent owns JSONL+SQLite. |
| 3 |
nix2cf: buildfile first, conflict, extra-entry, then inference (needs steps 1–2). |
nix2cf is Step 3, and the table says it needs both 1 and 2. It was never
"approved scope sitting idle" — it's blocked on a stated dependency.
Where the dependency actually stands
- Step 1 (macOS services adapter): real progress this session.
policy/tendcf_services.cf (generic bundle, 222da45) renders
present/absent + interlock refusal for launchd services, verified
against a real cf-agent build. Dry-run default, no nix-darwin —
matches the spec. Not complete (systemd/runit, unit-writer detector,
secretspec env resolution are named follow-ups in that commit), but
the core adapter now exists and is proven.
- Step 2 (Android/Termux): not started. No Termux types in the
schema, no agent JSONL/SQLite ownership code, nothing.
Decision
nix2cf stays out of scope until Step 2 lands, not because it was
forgotten but because starting the compiler before both its declared
inputs (steps 1 and 2) exist risks building against an adapter shape
that Step 2's Android work may still change. This isn't a new call —
it's making the existing build-order table's dependency explicit as an
actual decision, since the last three handoffs treated it as scope
drift instead.
Re-open / revisit when
Step 2 (Android under the Site Model, Termux types, agent JSONL+SQLite)
has real code, the same bar Step 1 just cleared this session. At that
point nix2cf's actual scope (buildfile → conflict → extra-entry →
inference, per the table) is the next real design conversation, not a
"we forgot" one.
Why this needed a decision, not just a reminder
docs/handoffs/HANDOFF_standalone-3fd9_projector-gate-findings-closed_2026-08-16_7c19.mdnamed nix2cf as "in the operator's approved scope for two sessions now and
still never touched," framed as something at risk of being forgotten a
third time. That framing undersold what's actually going on.
architecture-DEFINITIVE-v3.md's own build-order table (line ~946) isexplicit:
buildfilefirst, conflict, extra-entry, then inference (needs steps 1–2).nix2cf is Step 3, and the table says it needs both 1 and 2. It was never
"approved scope sitting idle" — it's blocked on a stated dependency.
Where the dependency actually stands
policy/tendcf_services.cf(generic bundle,222da45) renderspresent/absent + interlock refusal for launchd services, verified
against a real
cf-agentbuild. Dry-run default, no nix-darwin —matches the spec. Not complete (systemd/runit, unit-writer detector,
secretspec env resolution are named follow-ups in that commit), but
the core adapter now exists and is proven.
schema, no agent JSONL/SQLite ownership code, nothing.
Decision
nix2cf stays out of scope until Step 2 lands, not because it was
forgotten but because starting the compiler before both its declared
inputs (steps 1 and 2) exist risks building against an adapter shape
that Step 2's Android work may still change. This isn't a new call —
it's making the existing build-order table's dependency explicit as an
actual decision, since the last three handoffs treated it as scope
drift instead.
Re-open / revisit when
Step 2 (Android under the Site Model, Termux types, agent JSONL+SQLite)
has real code, the same bar Step 1 just cleared this session. At that
point nix2cf's actual scope (buildfile → conflict → extra-entry →
inference, per the table) is the next real design conversation, not a
"we forgot" one.