v1.8.2 — data-model stack-agnostic + derived from architecture; roadmap as tables#5
Merged
Merged
Conversation
…onventions, drop the rules file (v1.8.2) data-model imposed a DB-as-dumb-storage philosophy (UUID v7 / no updated_at / hard delete / no CHECK / bounded VARCHAR) and bootstrapped a `.claude/rules/migrations.md` to legislate it — inconsistent with the plugin's stack-agnostic ethos. It now detects the repo's DB + migration conventions (from the live migrations/, the schema, CLAUDE.md) and FOLLOWS them; on greenfield it confirms each choice with the user. No rules file is written. - "Defaults (opinionated set)" table → "Conventions: detect and follow" (philosophy topics — naming/PK/audit/delete/constraints/types — follow the repo; greenfield confirms). Universal migration SAFETY stays (staging + promote-at-implement, reversibility, FK indexes, expand/backfill/contract, no-PII) — that's stack-agnostic, not DB philosophy. - Step 2 rules-bootstrap removed; the self-check drops the CHECK/TRIGGER grep and adds "convention adherence"; anti-patterns drop the philosophy ones and add "imposing a DB philosophy the repo didn't ask for". - Deleted templates/migrations-baseline.md; reconciled the data-model.md template comments + survey's architecture-map reference. validate_plugin.py: 177 checks pass; 300 markdown links resolve. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ure, not ad-hoc repo detection The migration tool/naming and the DB approach (PK / audit / delete / constraints) are now derived PRIMARILY from the architecture — architecture-map.md §Migrations (what survey recorded) + the sad.md persistence decisions (§4/§5/§8) + Accepted ADRs — and the live migrations/ + schema only CORROBORATE (filling what the architecture left implicit, e.g. statement-per-file rules / the next sequence value). Greenfield with no architecture signal → confirm with the user. Flag any architecture-vs-repo divergence in the audit report. Still stack-agnostic; still no rules file. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…; Next already tabular) docs/roadmap.md now renders Now, Later, and Shipped as tables (Next was already a RICE table), so the whole board is a consistent table rather than mixed bullets. Columns: Now = Outcome | Feature | Status; Later = Outcome / theme; Shipped = Date | Outcome | Feature | PR. The skill notes the board is table-rendered, one row per item. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Owner
Author
|
Two follow-ups from review folded in (still v1.8.2):
|
genkovich
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
data-modelwas the one skill that imposed a DB philosophy — DB-as-dumb-storage (UUID v7 app-side,created_at-only / noupdated_at, hard delete, noCHECK/triggers, boundedVARCHAR) — and bootstrapped.claude/rules/migrations.mdto legislate it. That contradicts the plugin's stack-agnostic ethos (every other skill detects what the repo uses). This makesdata-modelstack-agnostic.Change
data-modelnow reads the repo's DB + migration conventions (the livemigrations/, the schema,CLAUDE.md/ the architecture map) and follows them — naming, PK strategy, audit columns, delete strategy, constraint usage (CHECK/triggers/DEFAULT), string/JSON types. On a greenfield repo with no signal it confirms each choice with the user instead of defaulting to a house style..claude/rules/migrations.mdbootstrap is gone;templates/migrations-baseline.mddeleted.docs/features/<slug>/migrations/+ promote-at-implement, a.downfor every.up, an index on every FK + one per real query, expand→backfill→contract for breaking changes, no real PII in seeds.CHECK/TRIGGERgrep and adds convention adherence; anti-patterns drop the philosophy ones and add "imposing a DB philosophy the repo didn't ask for"; thedata-model.mdtemplate comments + survey's architecture-map reference reconciled.Verification
python3 scripts/validate_plugin.py→ 177 checks pass; manifests agree on 1.8.2.data-modelno longer creates a rules file (only an anti-pattern forbidding it); 300 markdown links resolve.🤖 Generated with Claude Code