bvandeusen
0f80b790c7
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 9s
CI & Build / integration (push) Successful in 19s
CI & Build / TypeScript typecheck (push) Failing after 20s
CI & Build / Python tests (push) Successful in 44s
CI & Build / Build & push image (push) Skipped
Last piece of the architecture in #2296. The operator: "the prose doesn't have to live as one offs, there's a central system for managing it." Two fields, both free-form: design_systems.guidance the narrative a token table cannot hold — aesthetic, voice and tone, what is deliberately out of scope. design_tokens.rationale WHY a token is this value, which is a different question from `purpose` (what it is FOR). "Success equals Moss, aligned by design" is a rationale; "page bg, deepest surface" is a purpose. Rules carry the first routinely and a token row had nowhere to put it. Free-form rather than a column per category, deliberately. A schema with `voice`, `aesthetic` and `scope` columns would bake one rulebook's table of contents into every install (rule #115), leaving the next install three empty columns and nowhere for what it actually cares about. Both nullable: a design system with no prose at all is complete, not a draft. `rationale` cascades like `purpose` — deepest non-empty wins — so an app overriding a colour keeps the family's reasoning rather than blanking it. Same argument as `supersedes`: the override was about the value, not the meaning. In the generated sheet the inline comment prefers `purpose` and falls back to `rationale`, so a token carrying only the why still says something instead of rendering bare.
45 lines
1.6 KiB
Python
45 lines
1.6 KiB
Python
"""central prose on a design system, and rationale on a token
|
|
|
|
Revision ID: 0074
|
|
Revises: 0073
|
|
Create Date: 2026-07-31
|
|
|
|
The operator's shape for #254: prose doesn't live as one-offs, it lives centrally
|
|
on the system. Two fields rather than one per category:
|
|
|
|
design_systems.guidance the narrative a token table cannot hold — aesthetic,
|
|
voice and tone, what is deliberately out of scope.
|
|
Markdown, free-form.
|
|
design_tokens.rationale WHY this token is this value, which is a different
|
|
question from `purpose` (what it is FOR). "Success
|
|
equals Moss, aligned by design" is a rationale;
|
|
"page bg, deepest surface" is a purpose.
|
|
|
|
Free-form rather than a column per category on purpose. A schema with `voice`,
|
|
`aesthetic` and `scope` columns would bake one rulebook's table of contents into
|
|
every install (rule #115), and the next install's design system would have three
|
|
empty columns and nowhere to put what it actually cares about.
|
|
|
|
Both nullable: a design system with no prose at all is complete, not a draft.
|
|
|
|
Downgrade drops both columns and the prose with them.
|
|
"""
|
|
from alembic import op
|
|
import sqlalchemy as sa
|
|
|
|
|
|
revision = "0074"
|
|
down_revision = "0073"
|
|
branch_labels = None
|
|
depends_on = None
|
|
|
|
|
|
def upgrade() -> None:
|
|
op.add_column("design_systems", sa.Column("guidance", sa.Text(), nullable=True))
|
|
op.add_column("design_tokens", sa.Column("rationale", sa.Text(), nullable=True))
|
|
|
|
|
|
def downgrade() -> None:
|
|
op.drop_column("design_tokens", "rationale")
|
|
op.drop_column("design_systems", "guidance")
|