feat(directives): scavenge sweep 2/5 batch 2 (ui polish+sepia): 5 directives
This commit is contained in:
@@ -0,0 +1,9 @@
|
||||
# float_only_math_for_visual_transforms
|
||||
|
||||
## v1
|
||||
|
||||
**Why this iteration:** Lifted from `docs/superpowers/specs/2026-06-10-prior-session-sepia-design.md` §"Q4. Float-only math (HARD CONSTRAINT)" (lines 59-66) + §"Float-only math contract" (lines 105-114). The user's verbatim requirement: "Make sure that all math you do is not integer based. I want to have as much accuracy as possible for smooth calculations." Applied to: per-palette state dicts store `float` not `int`; sliders use `slider_float` not `slider_int`; TOML keys store `float`; transform pipelines never truncate to int mid-pipeline (desaturate, lerp, gamma, all stay in `[0.0, 1.0]` float range; output is `tuple[float, float, float, float]`). Integer math in a color transform produces visible banding under smooth animation; float is the contract.
|
||||
**Source:** `docs/superpowers/specs/2026-06-10-prior-session-sepia-design.md:59-66 + 105-114`
|
||||
|
||||
---
|
||||
**Lifted:** 2026-07-03 (scavenge sweep batch 2/5: docs/superpowers/specs/)
|
||||
@@ -0,0 +1 @@
|
||||
# Visual transform pipelines must use float-only math end-to-end (no integer truncation in color, tint, blur, or animation math)
|
||||
@@ -0,0 +1,9 @@
|
||||
# interceptor_activates_only_on_matching_shape
|
||||
|
||||
## v1
|
||||
|
||||
**Why this iteration:** Lifted from `docs/superpowers/specs/2026-06-03-ui-polish-design.md` §"Phase 1 — Markdown Table Pre-Processor" (lines 64-90). When intercepting a third-party text renderer (e.g., `imgui_md`) to add a feature the upstream doesn't support (e.g., GFM tables), the interceptor must (a) detect the target block via a strict shape signature, (b) fall back to the upstream pass when the shape doesn't match, and (c) only mutate the matched blocks. Pass-through for non-matching input is the safety property; the upstream renderer's correctness for non-target content must be preserved.
|
||||
**Source:** `docs/superpowers/specs/2026-06-03-ui-polish-design.md:64-90`
|
||||
|
||||
---
|
||||
**Lifted:** 2026-07-03 (scavenge sweep batch 2/5: docs/superpowers/specs/)
|
||||
@@ -0,0 +1 @@
|
||||
# Text-processing interceptors must activate only when the input matches the target shape; everything else passes through unchanged
|
||||
@@ -0,0 +1,9 @@
|
||||
# missing_data_renders_as_em_dash_not_crash
|
||||
|
||||
## v1
|
||||
|
||||
**Why this iteration:** Lifted from `docs/superpowers/specs/2026-06-03-ui-polish-design.md` §"Phase 4 — Operations Hub > Vendor State Panel" (lines 203-208). The acceptance criterion is explicit: "Missing data renders as `—` (em dash), not as a crash." When a UI table aggregates from a data source that may be absent (e.g., vendor quota on a provider that doesn't expose one, or last-error class when no error has occurred), the renderer must emit a stable, recognizable sentinel for the missing value rather than raising. The em dash is the convention because it is visually distinct, copy-paste neutral, and not confusable with any real value.
|
||||
**Source:** `docs/superpowers/specs/2026-06-03-ui-polish-design.md:206-208`
|
||||
|
||||
---
|
||||
**Lifted:** 2026-07-03 (scavenge sweep batch 2/5: docs/superpowers/specs/)
|
||||
@@ -0,0 +1 @@
|
||||
# Missing data renders as `—` (em dash), not a crash
|
||||
@@ -0,0 +1,9 @@
|
||||
# surface_upstream_api_limits_honestly_in_spec
|
||||
|
||||
## v1
|
||||
|
||||
**Why this iteration:** Lifted from `docs/superpowers/specs/2026-06-10-prior-session-sepia-design.md` §"Honest constraint surfaced during self-review" (lines 75-95). When a spec proposes a feature that depends on an upstream library API surface that does not actually exist (here: a mutable `Palette` struct in `imgui_bundle.imgui_color_text_edit` — verified against the live API, the struct is not exposed, only a 4-value `PaletteId` enum), the agent must (a) verify the upstream API before writing the plan, (b) call out the limit explicitly in the spec with a dedicated section, and (c) tell the user upfront that the originally-proposed approach cannot be implemented as designed. Hand-waving past the limit or working around it silently leaves the user's expectation unaddressed; honest disclosure lets the user decide whether to accept the limit, fork the library, or drop the feature.
|
||||
**Source:** `docs/superpowers/specs/2026-06-10-prior-session-sepia-design.md:75-95`
|
||||
|
||||
---
|
||||
**Lifted:** 2026-07-03 (scavenge sweep batch 2/5: docs/superpowers/specs/)
|
||||
@@ -0,0 +1 @@
|
||||
# When an upstream library does not support a needed capability, surface the limit explicitly in the spec — do not hand-wave past it
|
||||
@@ -0,0 +1,9 @@
|
||||
# view_composes_does_not_leak_into_theme_get_color
|
||||
|
||||
## v1
|
||||
|
||||
**Why this iteration:** Lifted from `docs/superpowers/specs/2026-06-10-prior-session-sepia-design.md` §"Why A1 over A2 (transparent via get_color) and A3 (context manager)" (lines 96-103). Auto-applying a view-state transform inside `theme.get_color()` (e.g., sepia tint when `is_viewing_prior_session == True`) violates the data-oriented principle that "view composes": the data layer returns raw theme slots, and the view layer applies per-site transforms explicitly. The risk of putting the transform inside `get_color` is that status indicators, badges, and other elements that must stay at full saturation get accidentally tinted. The correct pattern is per-render explicit wraps (A1): each prior-session rendering site wraps its `theme.get_color()` call with the transform function, one line per site, scoped to what needs the tint.
|
||||
**Source:** `docs/superpowers/specs/2026-06-10-prior-session-sepia-design.md:96-103`
|
||||
|
||||
---
|
||||
**Lifted:** 2026-07-03 (scavenge sweep batch 2/5: docs/superpowers/specs/)
|
||||
@@ -0,0 +1 @@
|
||||
# Theme get_color must not apply view-state transforms; view composes, not the data layer
|
||||
Reference in New Issue
Block a user