Backlog Roundup — Two Pre-Rule Features That Stay Roundup-Only
- Version
- vpre-v5.0
- Date
- 2026-04-20
- Tier
- light
Roundup of two features that pre-date the 2026-04-13 "every feature gets a case study" rule and have source material too thin to support a dedicated case study. Honest accounting: state.json + commits exist; PRD/research/tasks do not. Writing dedicated case studies for these would require either fabrication or file-tour redundancy with the PR diff. Three sibling features (gdpr-compliance, google-analytics, android-design-system) split out into their own case studies on 2026-05-05 because their source material is dense.
- •These two features genuinely lack rich source material. The honest record is "shipped pre-rule, captured retroactively via state.json + PR." A dedicated case study would have to either fabricate PM decisions that weren't made, or be a file-tour redundant with the PR diff.
- •
development-dashboardis the only feature in the project that's a standalone Astro/React web app, not iOS code. Its rich material is post-merge stabilization (~10 follow-up commits made it useful) — but each individual fix is small, and "many small fixes stabilized the dashboard" is thin narrative. - •
ai-cohort-intelligence(federated learning engine) has 1 transition (init → completeon 2026-04-06) and a backfill note. PR #12 + state.json + the file diff is the only historical artifact. - •This roundup MDX is the housekeeping replacement for the original 6-feature roundup. The 3 dense siblings now have dedicated showcases at slot 24a/24b/24c. The 6th feature in the original roundup (
stats-v2) had its own dedicated case study before this split. - •Originally drafted 2026-04-20. Narrowed and republished 2026-05-05 as part of the chain-of-custody initiative (full-repair-mode plan, Decision 3 + Q1 = Option 3 hybrid split).
How to read this case studyT1/T2/T3 · ledger · kill criterion▾
- T1Instrumented
- Numbers come from a machine-generated ledger or commit. Reproducible. Highest reader trust.
- T2Declared
- Numbers stated by a structured declaration (PRD, plan, frontmatter) but not directly measured.
- T3Narrative
- Estimates and observations from session memory. Useful for context; not citable as evidence.
- Ledger
- Where to verify the claim — a file path, GitHub issue, or backlog entry. Anything labelled
ledger:is the audit trail. - Kill criterion
- The pre-registered threshold under which this work would have been killed mid-flight. Not fired = work shipped without hitting the threshold.
- Deferred
- Items intentionally not closed in this version. Each cites the ledger that tracks remaining work.
Visual aid · key numbers at a glance
Default · no specialised visual declared- Not applicable — these are roundup entries for shipped pre-rule features. They cannot be killed; they're historical record.
Why this roundup exists
The project rule from 2026-04-13 says every feature gets a case study. Some features pre-date that rule and have source material too thin to honestly support a dedicated case study.
The 2026-04-20 six-features-roundup acknowledged this with an explicit stratification: 3 dense + 3 thin. The 3 dense ones were kept in the roundup at the time because consolidation was cleaner than mixing formats with the dedicated case studies the project was writing for post-rule features.
On 2026-05-05, the chain-of-custody initiative re-evaluated. The 3 dense ones (gdpr-compliance, google-analytics, android-design-system) were split into dedicated case studies because their source material justified it. The 2 thin ones (this roundup) stay roundup-only.
The two features
development-dashboard
One-line headline: The only feature in the project that's a standalone Astro/React web app rather than iOS code, with a full 10-transition PM lifecycle recorded and a long tail of follow-up fixes.
| Field | Value |
|---|---|
| Scope | dashboard/ — Astro + React + Tailwind v4 web app deployed on Vercel |
| Merge | 7f69d07 (--no-ff) + ~10 post-merge fixes |
| Wall time | ~6 hours initial, ~weeks of stabilization |
| Tests | 9/9 reconcile tests pass |
| Why thin | Web app off the iOS platform; rich material is post-merge fixes which are individually small |
ai-cohort-intelligence
One-line headline: A federated learning engine that shipped before the PM workflow existed, captured retroactively with a single state transition.
| Field | Value |
|---|---|
| Scope | AI engine (Python FastAPI) + iOS AI orchestration layer |
| PR | #12 (32f27bf) |
| Files | ~30+ new files (ai-engine/app/ tree + FitTracker/AI/) |
| Transitions | 1 (init → complete on 2026-04-06) |
| Why thin | No research.md, no tasks.md, no UX spec, no phase-by-phase log. State.json explicitly marks Research/Tasks/UX/Testing/Review as pre-pm-workflow. |
Cross-feature lesson
Pre-rule features should be backfilled honestly, not narratively. Some features just have a state.json and a PR. That's the correct record. Writing a dedicated case study for them would require either inventing PM decisions that weren't made (fabrication) or producing a file-tour that's redundant with the PR diff. The roundup format handles this cleanly: acknowledge the feature exists, name what shipped from the PR stats, link the backfilled state.json, and stop. The case_study_type: pre_pm_workflow_backfill tag in state.json is the schema record of this exemption.
Links
- FT2 source:
docs/case-studies/six-features-roundup-case-study.md - Sibling split-out case studies (dense features from same roundup):
- Sibling already-dedicated case study:
22c-stats-v2