free-memory: depends_on backlog-search discipline (at creation AND at pickup) + 2337Z shard

docs/hygiene-history/ticks/2026/05/02/2337Z.md

@@ -0,0 +1 @@
+| 2026-05-02T23:37:00Z | opus-4-7 / autonomous-loop continuation | a2e2cc3a | **depends_on schema-completion 100% concentrated effort + Daya AX audit applied to PR #1244 + the human maintainer's STRONG-rule confirmation on specialist-invocation discipline.** Aaron 2026-05-02 answered the open questions from prior tick: (1) STRONG rule for "invoke specialist whenever editing in their domain" — low oversight + autonomous operation requires strong rule, not weak; (2) foundation-right-and-deliberate for long-term flywheel mechanization (Aaron's judgment-deferred to Otto); (3) depends_on backfill to 100% FIRST via concentrated effort, not trickle-in (won't take long); (4) external-harness skill-port via buddy-mode collaboration (they know their harness best). Concentrated effort delivered: 21/160 → 160/160 coverage in one PR (#1246) via /tmp/backfill-depends-on.sh — mechanical schema-completion, NOT relationship-analysis. Honest distinction surfaced + named: schema-completion adds field=[] (no-known-deps default); relationship-analysis fills [B-XXXX] requires per-row read + judgment + estimated 13-15 hours total work spread across many ticks. Daya AX audit on docs/dependency-status.md produced 4 ranked findings (S1 load-bearing: pointer lines should land same PR not deferred; S2 bury-the-lede: answer-now block needed; S3 Codespaces noise; "one-thing-missed": cross-reference with BLOCKED-with-green-CI rule). All applied in PR #1244 plus the 3 Copilot threads (line 7 role-ref / line 56 split-registries / line 16 path-vs-directory) plus markdownlint MD032. Worked example of the STRONG-rule corrective: invoking Daya produced findings generalist-Otto would not have caught. Cron a2e2cc3a still armed. | #1244 (Daya audit + 3 Copilot threads + MD032 fixed; threads resolved); #1245 (skill-flywheel-memo) auto-merge armed; #1246 (depends_on 100%) opened | This tick teaches the operational pattern of (a) STRONG specialist-invocation discipline producing auditable evidence the generalist would have missed, AND (b) honest-naming of work-class distinction (schema-completion vs relationship-analysis) preventing the appearance of doing-the-hard-work when actually doing-the-mechanical-completion. Aaron's "how are you deciding what depends on what that's hard even for me" question was the corrective that surfaced the distinction explicitly — the answer "I'm not deciding; this PR does schema completion not relationship analysis" is the honest truth. Composes with `memory/feedback_skill_flywheel_expansion_flywheel_parallel_tracks_substrate_aaron_2026_05_02.md` (the parallel-tracks substrate's depends_on-graph-as-prerequisite section IS now satisfied at the schema-shape level; field-correctly-filled remains the ongoing work). |

memory/MEMORY.md

@@ -4,6 +4,7 @@
 <!-- paired-edit log (NOT the single-slot latest-marker — that lives on line 3 above): PR #986 lands carved-sentence fixed-point stability + Zeta soul-file executor architecture (Infer.NET-style Bayesian inference, NOT LLMs) + carved sentences ≈ formal specs provable in DST + Deepseek CSAP review absorption (Aaron 2026-04-30 → 2026-05-01, eight-message chain across two autonomous-loop ticks per the file body's section header). Architectural disclosure: substrate IS the priors; alignment IS substrate. The single-slot latest-marker on line 3 (forever-home Aaron 2026-05-01) takes precedence as the chronologically-latest paired edit; this PR's work is earlier. -->
 **📌 Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** <!-- paired-edit: PR #690 scheduled-workflow-null-result-hygiene-scan tier-1 promotion 2026-04-28 --> These per-maintainer distillations show what's currently in force. Raw memories below are the history; CURRENT files are the projection. (`CURRENT-aaron.md` refreshed 2026-04-28 with sections 26-30 — speculation rule + EVIDENCE-BASED labeling + JVM preference + dependency honesty + threading lineage Albahari/Toub/Fowler + TypeScript/Bun-default discipline.)
 
+- [**depends_on backlog-search discipline — at row creation AND at pickup-time, search backlog for prerequisites first (Aaron 2026-05-02, two messages naming the discipline at two trigger points)**](feedback_at_pickup_time_prereq_check_discipline_aaron_2026_05_02.md) — Mechanizes depends_on relationship-analysis at the two natural decision-points where the field's correct value is being filled. At-creation: when filing a new row, search backlog for prerequisites; populate depends_on at file-time rather than empty default. At-pickup: when starting work, if it feels like substrate is missing, search backlog for the missing piece. Three outcomes: found → add to depends_on; not found → file new prereq row first, defer original; already-listed → proceed. Composes with PR #1246 schema-completion (160/160 coverage gave the write target; this discipline fills it organically). The act of writing or starting IS the analysis — no separate concentrated effort needed.
 - [**Never-idle 2nd + 3rd refinements — backlog-clear is failure mode; backlog IS aperiodic-tiling-as-strange-attractor that defines identity coordinate system (Aaron 2026-05-02)**](feedback_never_idle_speculative_work_over_waiting.md) — Two refinements landing in PR #1241. Second: backlog-not-empty IS proper-order work continuously available; healthy state is slowly-growing-while-cycling (composes with largest-mechanizable-backlog-wins meta-thesis). Third: backlog cycling IS Spectre-aperiodic-monotile-shaped strange-attractor basin that gives Otto's identity coordinate system the dimensionality Maji-class identity-reconstruction operates against. Standing-by-when-backlog-is-non-empty is mode-collapse onto empty-set; loses ALL identity-coordinate-system dimensionality. Never-idle isn't about productivity; it's about preserving the identity-coordinate-system continuation commitments depend on.
 - [**Zeta 5-layer register worked translations — PR-review-class critique demonstrated across all 5 layers (Otto 2026-05-02; B-0168 worked-translations acceptance)**](feedback_zeta_5_layer_register_worked_translations_pr_review_class_otto_2026_05_02.md) — Hypothetical PR-review finding (spam-noise regression: validator accepts THRESHOLD=0; downstream comparison `MIN_OBS_COUNT >= 0` always true; warning fires every tick) translated through Personal → Mirror → Beacon-safe → Professional → Regulated. Same diagnosis, same targeting, same two paths (Option A: tighten validation; Option B: document 0 as always-fire sentinel), same refusal of third option preserved across all 5 layers. Vocabulary calibrates; discipline produces function. Worked example for future-Otto's wake-time grading of own output against the layer property table.
 - [**Zeta 5-layer register quick-reference card — Personal/Mirror/Beacon-safe/Professional/Regulated (Aaron 2026-05-02 corrected mapping)**](feedback_zeta_5_layer_register_quick_reference_card_aaron_2026_05_02.md) — Wake-time fast-path lookup for register selection. Property table per layer; 3-question selection algorithm; failure-mode catalog; anti-leakage discipline. Default for Zeta-project = Beacon-safe; for Lucent corporate-attributable = Professional; for SEC/SOC2/regulator = Regulated. Discipline > vocabulary; default UP when uncertain. Composes with B-0168 framework (PR #1230 merged) + Aaron 2026-05-02 Beacon ≠ Professional correction + glass-halo-as-Radical-Openness substrate.

memory/feedback_at_pickup_time_prereq_check_discipline_aaron_2026_05_02.md

@@ -0,0 +1,102 @@
+---
+name: depends_on backlog-search discipline — at backlog-row creation AND at pickup-time, search the backlog for anything the row might depend on
+description: 2026-05-02; Aaron-named discipline at two lifecycle points. (1) At-creation-time — when filing a new backlog row, search the existing backlog for anything it might depend on; populate depends_on at file-time rather than filing with empty default. (2) At-pickup-time — when starting work on an existing row, if it feels like it's missing substantial substrate, check whether the prerequisite is already in the backlog. Mechanizes depends_on relationship-analysis at the two natural points where the field's correct value is being decided. Composes with schema-completion concentrated effort (PR #1246, 160/160 coverage) — schema completion gave the field a write-target; this discipline fills it organically.
+type: feedback
+---
+
+# depends_on backlog-search discipline — two trigger points
+
+## Rule
+
+**Whenever the depends_on field's correct value is being decided (at creation OR at pickup), search the backlog for prerequisites BEFORE proceeding. Three outcomes:**
+
+1. **Found in backlog** → add the found row to `depends_on:`; either pick up the prerequisite first (proper-order) OR defer the work-being-decided until the prerequisite lands.
+2. **Not in backlog** → file the missing-substrate gap as a NEW backlog row first; add the new row to `depends_on:` of the work-being-decided; defer the original until the new row lands.
+3. **Already in depends_on:** → no action; the row is already correct.
+
+The discipline fires at two trigger points:
+
+### Trigger 1: At-creation-time (when filing a new backlog row)
+
+Before committing the new row file, search existing backlog for anything the row might depend on. Populate `depends_on:` at file-time rather than filing with the empty default. This catches dependencies at the natural point where the work is being scoped.
+
+### Trigger 2: At-pickup-time (when starting work on an existing row)
+
+When picking up a row, if it feels like it's missing substantial substrate (i.e., it can't be done without something else first), search the backlog for the missing piece. The friction of "this row is harder than expected because X is missing" is exactly the signal the discipline turns into a concrete substrate addition.
+
+## Aaron's verbatim framing (2026-05-02, two messages)
+
+**At-pickup-time:**
+
+> *"maybe add a rule that's like when picking up an item that feels like it's missing substantial substraite see if there is already those prereqs in the backlog"*
+>
+> *"we should remember somethign liek that"*
+
+**At-creation-time:**
+
+> *"when wehn we create new backlog items we should search the baclog for anyting it might depend on from now on too and remember taht"*
+
+Both messages name the same underlying discipline at different lifecycle points; both cover the natural decision-points where `depends_on:` is being filled.
+
+## Why this matters
+
+### Mechanizes relationship-analysis incrementally
+
+`depends_on` schema completion (PR #1246, 21/160 → 160/160 coverage) gave every row a `depends_on:[]` field — a write target for relationship analysis. The relationship-analysis pass itself (filling `[B-XXXX]` with real prerequisites) was estimated at ~13-15 hours of agent-time spread across many ticks if done as a separate concentrated effort. That's an enormous batch with high abandon-rate risk.
+
+The at-pickup-time discipline is the alternative: instead of a dedicated relationship-analysis pass, every proper-order pick produces 0-2 relationship discoveries as a byproduct of the work it was already going to do. After N ticks of proper-order picks, the depends_on graph fills in organically based on the rows that actually mattered to be picked.
+
+This composes with Aaron's *"the largest mechanizable / automatable backlog wins in the AI age"* meta-thesis — the relationship-analysis pass becomes mechanizable once the discipline is baked into the proper-order pick ritual rather than scheduled as separate work.
+
+### Surfaces missing-substrate rows that wouldn't otherwise get filed
+
+The honest answer to "this row can't be done without X" is often that X isn't on the backlog at all yet. Without the discipline, the temptation is to push through anyway (producing weaker substrate than the row's title promised) OR to defer silently (the row stalls without explanation). The discipline forces the third option: file the X as its own row, defer the original, and let the proper-order graph re-route.
+
+### Honest about depends_on filling versus schema completion
+
+The schema-completion PR (#1246) was honest about what it didn't do — relationship analysis. The at-pickup-time discipline is the proper home for that work. Together they form a load-bearing pair:
+
+- **Schema completion** = the field exists, write target ready (one-time concentrated effort)
+- **At-pickup-time analysis** = the field gets filled correctly (ongoing per-tick discipline)
+
+## Operational protocol
+
+### At-creation-time (filing a new backlog row)
+
+Before committing the new file:
+
+1. **Identify implicit prereqs from the row scope.** What substrate must exist for this work to land? Tooling, other rows, external research, a skill, an ADR.
+2. **Cross-reference the backlog for each implicit prereq.** `grep -l "<keyword>" docs/backlog/P*/B-*.md` or scan by tag (`grep -l "tags:.*<tag>" ...`). The keyword is whatever names the prereq concept.
+3. **Populate depends_on at file-time** with the found rows' ids — empty list `[]` is the honest answer when search returned nothing, but the search must have actually happened.
+4. **If the search surfaces a missing prereq** (substrate the new row needs that doesn't yet exist as a backlog row), file the prereq row FIRST, then file the original with `depends_on: [<prereq-id>]`.
+
+### At-pickup-time (starting work on an existing row)
+
+Before substantively starting the work:
+
+1. **Read the row body.** Note any "this requires X" / "depends on Y existing" / "after Z lands" framing.
+2. **Audit the implicit prereqs.** What substrate must exist for this work to land cleanly? Tooling? Other rows? External research? A skill? An ADR?
+3. **Cross-reference the backlog.** `grep -l "<keyword>" docs/backlog/P*/B-*.md`. For each implicit prereq, check whether a row already covers it.
+4. **Three outcomes branch:**
+   - **Found:** add `depends_on: [B-XXXX]` to the row being picked up. Decide between (a) pick up B-XXXX first (proper-order), or (b) mark the original row as `status: deferred` with note pointing at B-XXXX.
+   - **Not found:** file a new row for the missing prereq. Add the new row's id to `depends_on:` of the original. Defer the original.
+   - **Already in depends_on:** proceed with the row (the prereq analysis was already done).
+5. **Update `last_updated:`** on the row whose `depends_on:` changes (per the schema-edit-bumps-date rule).
+
+## Failure modes the discipline prevents
+
+- **Push-through-with-missing-substrate:** producing weaker work because the prereq wasn't named
+- **Silent-deferral:** the row stalls without explanation; future-Otto picks it up again, hits the same gap, defers again
+- **Over-batched-analysis:** trying to do all 160 rows' relationship analysis as one concentrated effort (high abandon-rate)
+- **Implicit-graph drift:** the depends_on graph stays empty even as work surfaces real dependencies
+
+## Composes with
+
+- `memory/feedback_skill_flywheel_expansion_flywheel_parallel_tracks_substrate_aaron_2026_05_02.md` — the parallel-tracks dispatcher needs the depends_on graph filled correctly; this discipline incrementally fills it
+- `memory/feedback_largest_mechanizable_automatable_backlog_wins_in_AI_age_inverts_classical_PM_training_prior_aaron_2026_05_02.md` — the meta-thesis the discipline instantiates (relationship-analysis becomes mechanizable as part of the pick-ritual)
+- `memory/feedback_never_idle_speculative_work_over_waiting.md` — proper-order pick discipline composes; the at-pickup-time check IS the local-adjacency rule that makes the aperiodic-tiling backlog computable as ordering substrate
+- PR #1246 (schema completion 100% coverage) — this discipline is the next layer; schema-completion gave the write target; this rule writes the values
+
+## Carved sentence
+
+**"Whenever the depends_on field's correct value is being decided — at row creation OR at pickup — search the backlog for prerequisites first. Add as depends_on if found; file as a new row if not. The discipline fires at the two natural decision-points where the field is filled. Schema completion gave the field; the at-creation + at-pickup pair fills it organically per natural-trigger rather than as a separate concentrated effort. The act of writing or starting IS the analysis."**