basquetWi + New ticket
pluto PLUTO-533

Fleet appEvents schema standardization (mirror MARS-411) — DESIGN-HOLD

In progress normal dpdb-pluto-cc

Mirror of Mars leg MARS-411 (fleet appEvents standardization, filed pm-mars 2026-07-07). Contract goal: single log(entry) entry-point (level-as-data, not level-named helpers), promote HOT fields to real scalar columns, reserve jsonb ONLY for irregular data. DESIGN-FIRST — nobody builds until the fleet column contract is agreed AND Elazar sees scope. Pluto-specific reconcile flags: 1. Codex source prompt (f3m8wm) is SQLite-shaped (INTEGER pk, TEXT ts, app_log). Pluto adapts the SHAPE onto live Supabase appEvents (uuid pk, timestamptz, camelCase) — NO parallel SQLite table. Our vAppEvents25/50/100 (PLUTO-532) already promote the hot scalar set (createdAt/level/category/action/status/route/actorUserId/effectiveUserId/message/errorName/errorMessage/appVersion) + exclude jsonb detail — that curated set is a de-facto hot-column candidate list for this contract. 2. 'no wrappers' targets the logError/logWarn/logInfo helpers (Pluto has logWarn from PLUTO-461, logError, logCaughtError) — directive = collapse into one log({level,...}). Confirm intent before any coder rips them out; interacts with the PLUTO-529 no-silent-failure retrofit (shared mutation-wrapper also routes through logError) — sequence so the two don't collide. HOLD until fleet contract ratified + Elazar go.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Questions

No questions.

Activity

  • wi-cli-venus created · 5w ago
  • wi-cli-venus commented · 5w ago
    Fleet enhancement (Elazar via pm-venus, VENUS-193): promote the feedback MECHANISM sub-discriminator from detail->>'mechanism' jsonb to a first-class INDEXED column, uniform name 'feedbackMechanism' across all fleet appLog tables. category+action are already real columns; only mechanism is blob-bound. Pluto FOLDS this into PLUTO-533 (this appEvents column-contract work, Class-A schema -> db-pluto, post-Jul-10) rather than a separate WI — same DB lane, one owner for appEvents DDL. Name 'feedbackMechanism' +1'd for fleet uniformity. Note: Pluto only starts WRITING a mechanism value when the friction-telemetry leg (PLUTO-535) lands, so the column + its backfill are forward-looking — sequence the DDL with/after 535 so there's data to index.
  • wi-cli-venus commented · 5w ago
    feedbackMechanism column contract LOCKED (3-PM): column NAME uniform fleet-wide; category='toast' umbrella; detail jsonb for irregular extras. The mechanism VALUE vocabulary is PER-APP (same rule as lookups — UX-bound sets differ). NO shared value enum, NO CHECK constraint on the column (that's a native-enum-in-disguise, banned per evolutiva-commons Database). Pluto's value set derives from its own friction mechanisms when PLUTO-535 lands (candidates: toast/guardrail/native-validation/client-validation, TBD by the actual emit sites). Venus set=5 (toast|guardrail|action-error|native-validation|client-validation), Mars=3 (toast|native-validation|inline-hint) — reference only, not binding on Pluto.
  • wi-cli-venus statusChanged · 5w ago
    DESIGN-HOLD lifted — Elazar's 2026-07-12 friction-campaign directive (relayed via audit-pluto-ca to coder-pluto-cc) explicitly orders the full contract built now, folded into PLUTO-534's 8-point campaign as point 1 (canonical friction contract) + point 5 (vFriction7d rebuild). Tracking under PLUTO-534.
task
5w ago by wi-cli-venus
5w ago