Found by the /do-docs cascade on PR #3315 (lane 3, #3215) while tracing cross-file couplings; it is a code-level inconsistency, outside a docs cascade's remit, so it is filed rather than patched.
What disagrees
reflections/improvement_controller_tick.py and reflections/improvement_intent_reconcile.py (lane 3) resolve their project key from config.memory_defaults.DEFAULT_PROJECT_KEY, which is "default". reflections/improvement_collect.py (lane 2) does the same.tools/improvement.py hardcodes PROJECT_KEY = "valor"; ui/app.py's /_partials/improvement/* routes default project_key="valor"; ImprovementCharter.pinned(project_key="valor"); tools/cross_vendor_judge.py records its receipt under project_key="valor"; ui/data/improvement.py getters default to "valor".
Consequence
ImprovementCase, ImprovementCharter, ImprovementEvidence, and the improve:{project_key}:* control namespace all partition by project key. With the split as shipped, improvement-controller-tick scans open cases under default while valor-improve propose, the charter pin, and the dashboard read and write under valor. Nothing production-side creates ImprovementCase or ImprovementCharter rows yet (lane 5 opens the first case), so today this is latent; the first real case will make the tick and the CLI disagree on which partition holds it, and the dashboard's control panel will show nothing for what the tick admits.
Suggested resolution
Pick one resolver for the improvement subsystem (a single improvement_project_key() helper, or ImprovementSettings.project_key), route the two lane-3 reflections, improvement_collect, tools/improvement.py::PROJECT_KEY, the dashboard routes, ImprovementCharter.pinned, and the judge receipt through it, and pin it with one test that asserts every entry point resolves the same key. Lane 5 (#3217) is the natural owner since it opens the first case; the lane-3 hand-off note is in docs/features/improvement-controller.md.
Refs #3215, #3177.
Found by the /do-docs cascade on PR #3315 (lane 3, #3215) while tracing cross-file couplings; it is a code-level inconsistency, outside a docs cascade's remit, so it is filed rather than patched.
What disagrees
reflections/improvement_controller_tick.pyandreflections/improvement_intent_reconcile.py(lane 3) resolve their project key fromconfig.memory_defaults.DEFAULT_PROJECT_KEY, which is"default".reflections/improvement_collect.py(lane 2) does the same.tools/improvement.pyhardcodesPROJECT_KEY = "valor";ui/app.py's/_partials/improvement/*routes defaultproject_key="valor";ImprovementCharter.pinned(project_key="valor");tools/cross_vendor_judge.pyrecords its receipt underproject_key="valor";ui/data/improvement.pygetters default to"valor".Consequence
ImprovementCase,ImprovementCharter,ImprovementEvidence, and theimprove:{project_key}:*control namespace all partition by project key. With the split as shipped,improvement-controller-tickscans open cases underdefaultwhilevalor-improve propose, the charter pin, and the dashboard read and write undervalor. Nothing production-side createsImprovementCaseorImprovementCharterrows yet (lane 5 opens the first case), so today this is latent; the first real case will make the tick and the CLI disagree on which partition holds it, and the dashboard's control panel will show nothing for what the tick admits.Suggested resolution
Pick one resolver for the improvement subsystem (a single
improvement_project_key()helper, orImprovementSettings.project_key), route the two lane-3 reflections,improvement_collect,tools/improvement.py::PROJECT_KEY, the dashboard routes,ImprovementCharter.pinned, and the judge receipt through it, and pin it with one test that asserts every entry point resolves the same key. Lane 5 (#3217) is the natural owner since it opens the first case; the lane-3 hand-off note is indocs/features/improvement-controller.md.Refs #3215, #3177.