The app-artifacts coarse mutation handlers (createInsight, updateInsight, patchInsight, refreshDataTable, etc.) and the command vocabulary (commands.ts / applyCommands) are two write paths for the same intents. The project has an explicit no-backward-compatibility stance pre-release: the coarse path is not a supported compatibility surface — it is pending deletion in one cut, once its remaining callers move.
What (one cut, no transition window):
- Migrate the remaining callers (renderer artifact CRUD and the CSV ingest path) to
applyCommands / command vocabulary.
- Point the insight read path (
rowToInsight, useInsightView) at source.sourceType/source.sourceId instead of treating baseTableId as a table id.
- Drop
baseTableId from the Insight domain type and its dual-write in commands.ts.
- Delete the coarse handlers and their server registrations.
Why: two write paths diverge semantically — e.g. refreshDataTable silently no-ops on a missing id (0-row UPDATE) while the command path enforces existence and throws. Known shape hazard in the same area: insight-source baseTableId being resolved as a table id by useInsightView.
Ordering: blocked by the renderer storage migration off the legacy store (which moves most callers as a side effect) and the CSV-ingest caller migration. This issue is the deletion that follows.
Acceptance: all callers on the command vocabulary; coarse handlers + registrations deleted; baseTableId gone from the domain type; no behavior change in surviving flows.
Tracked internally as YW-157 (CSV caller), YW-163 (renderer storage migration), and the deletion ticket referencing this issue.
The app-artifacts coarse mutation handlers (
createInsight,updateInsight,patchInsight,refreshDataTable, etc.) and the command vocabulary (commands.ts/applyCommands) are two write paths for the same intents. The project has an explicit no-backward-compatibility stance pre-release: the coarse path is not a supported compatibility surface — it is pending deletion in one cut, once its remaining callers move.What (one cut, no transition window):
applyCommands/ command vocabulary.rowToInsight,useInsightView) atsource.sourceType/source.sourceIdinstead of treatingbaseTableIdas a table id.baseTableIdfrom theInsightdomain type and its dual-write incommands.ts.Why: two write paths diverge semantically — e.g.
refreshDataTablesilently no-ops on a missing id (0-row UPDATE) while the command path enforces existence and throws. Known shape hazard in the same area: insight-sourcebaseTableIdbeing resolved as a table id byuseInsightView.Ordering: blocked by the renderer storage migration off the legacy store (which moves most callers as a side effect) and the CSV-ingest caller migration. This issue is the deletion that follows.
Acceptance: all callers on the command vocabulary; coarse handlers + registrations deleted;
baseTableIdgone from the domain type; no behavior change in surviving flows.Tracked internally as YW-157 (CSV caller), YW-163 (renderer storage migration), and the deletion ticket referencing this issue.