diff --git a/docs/README.md b/docs/README.md index eb77f72..7e5cd66 100644 --- a/docs/README.md +++ b/docs/README.md @@ -102,7 +102,7 @@ If a doc spans areas, file it under its primary area only. Reference any adjacen - [2026-06-03-buiy-render-r11-color-forced-colors-verify](plans/2026-06-03-buiy-render-r11-color-forced-colors-verify.md) — color + forced-colors + verification (color-and-forced-colors.md). Consolidates the token resolver to the single canonical `render::color::resolve_token` (R1's mod.rs + R5's extract copies removed; missing-token `warn!` preserved in `resolve_named`; `SystemColor(kw)` resolved through the active theme); `SystemColorKeyword::{token, ALL}`; the forced-colors stub theme + main-world `Theme`-swap system (`BuiySet::Style`, before extract) + `Theme::is_changed()` re-resolve; the WCAG contrast helper (`buiy_verify` delegates to `render::color::contrast_ratio`, no dup — gate #9); and the gate-#11 static analyzers (token-flow + no-shadow-only-affordance) over a `CatalogPaint` seam. Headless-gated; the gate-#2 golden harness is GPU `#[ignore]`. **Final render-pipeline phase.** `[landed]` - [2026-06-07-render-gpu-verify-campaign](plans/2026-06-07-render-gpu-verify-campaign.md) — verified the R6–R11 GPU path on real hardware; built the deferred atlas-glyph + effect-compositor + node-draw GPU orchestration (R8b/R9 GPU consumers); added the `--ignored` GPU CI lane; fixed 4 real GPU bugs. `[landed]` - [Cross-phase follow-ups](plans/follow-ups.md) — rolling cross-phase deferral backlog (layout / render / text / verification items, with `LANDED` flips); intentionally undated. `[active]` -- [Buiy follow-ups drain](plans/2026-06-18-followups-drain.md) — campaign plan to drain every actionable open follow-up in `follow-ups.md` (layout / render / text-editing tracks by file-locality), updating each spec + backlog entry as it lands and re-classifying the blocked/superseded/deferred ones. `[active]` +- [Buiy follow-ups drain](plans/2026-06-18-followups-drain.md) — campaign plan to drain every actionable open follow-up in `follow-ups.md` (layout / render / text-editing tracks by file-locality), updating each spec + backlog entry as it lands and re-classifying the blocked/superseded/deferred ones. `[landed]` ### Text diff --git a/docs/plans/2026-06-18-followups-drain.md b/docs/plans/2026-06-18-followups-drain.md index 00d23b3..9e08302 100644 --- a/docs/plans/2026-06-18-followups-drain.md +++ b/docs/plans/2026-06-18-followups-drain.md @@ -1,7 +1,7 @@ # Buiy follow-ups drain — campaign plan **Date:** 2026-06-18 -**Status:** active +**Status:** landed (all 13 actionable slices merged: layout #69, text #74, render #75 [re-applied on Bevy 0.19-rc after the BSN migration]; superseded/deferred/blocked items re-classified in `follow-ups.md`) **Spec:** realizes the named deferrals in `docs/plans/follow-ups.md` against their originating specs (layout, render-pipeline, text-editing). **Goal:** Drain every *actionable* open follow-up in `docs/plans/follow-ups.md`, update the spec + follow-ups entry as each lands, and explicitly re-classify the ones that are blocked, superseded, speculative, or deliberately deferred — so the backlog reflects reality. diff --git a/docs/plans/follow-ups.md b/docs/plans/follow-ups.md index f23c5ed..3d747e5 100644 --- a/docs/plans/follow-ups.md +++ b/docs/plans/follow-ups.md @@ -139,6 +139,13 @@ known at try-evaluation time) but the term type is missing from **Originated:** Phase 6 + README § 5 open question. +**Status:** **Deferred (not built)** — reviewed by the follow-ups-drain campaign +(`2026-06-18-followups-drain.md`) and deliberately left deferred: both spec § 3.5 +and README § 5 gate this on "if profiling surfaces a hot path", and no profiling +evidence exists, so the cap would be a speculative unused knob. **Re-open +trigger:** a *measured* deeply-nested-fallback hot path against a perf budget. +The implementation sketch below stands when that trigger fires. + **Symptom:** an anchor with a deeply-nested `position_try` chain (e.g., 20+ fallbacks) is evaluated linearly. No cap is enforced. If profiling surfaces this as a hot path, a resource-configurable cap should bound @@ -165,7 +172,16 @@ to query, or a global `LayoutTree` with window-tagged entries. **Implementation sketch:** depends on `buiy-window-and-surface-design` (currently incomplete). Out of Phase 6 scope. -## Anchor positioning — anchor target IS sticky/table/multicol (Phase 7 interaction) +## Anchor positioning — anchor target IS sticky/table/multicol (Phase 7 interaction) — LANDED + +**Status:** **Landed** in Phase 7 (Task 9, the D1 fix), confirmed by the +follow-ups-drain campaign. `anchor_resolution` (6d) reads the anchor target's +position from `PostTaffyPositionOverrides.by_entity` (written by sticky 6a / +table 6b / multicol 6c) first, falling back to Taffy only when absent — exactly +**Option 1** below (the shared per-entity correction buffer all four sub-passes +contribute to). Tested end-to-end in +`tests/layout_sticky.rs::anchor_target_is_sticky_anchored_tracks_displaced_position`. +The original analysis follows. **Originated:** Phase 6 (architectural quirk surfaced during plan review). @@ -1115,9 +1131,13 @@ app, assert inline expected pixels, re-capture in a second fresh app, assertion-free placeholder, not a green test. - **Multi-reference reftest aggregation** — the `RefCase::multi` OR/AND aggregation (`reftests.md` § Reference independence #3) is specified but not - built; single-reference reftests cover the current pairings. + built; single-reference reftests cover the current pairings. (Follow-ups-drain + reviewed and left deferred — re-open when a real logical-vs-physical, ≥2-reference + pairing appears; building it now is tested-but-unused machinery.) - **`golden-prune` bin** — the advisory stale-positive pruner (`goldens.md` - § Stale-positive guard) is a design hook, machinery deferred. + § Stale-positive guard) is a design hook, machinery deferred. (Follow-ups-drain + reviewed and left deferred — re-open when the golden corpus grows enough that + stale positives are plausible; nothing to prune at the current few cells.) - **Object-store golden migration** — in-git PNGs until the named trigger (>50 MB total or >500 positives); the `GoldenKey`/`BlessLedger` schema is fixed now so the migration is mechanical (`goldens.md` § Storage staging).