bvandeusenandClaude Opus 5
3345be84d1
Rule 27 — the milestone was backend-only until this. Four surfaces:
RULE EDITOR — verify_with and expires_when under a legend that asks the
actual question ("Can this rule go stale?") and says empty is the normal
answer, because most rules are decisions and a form that implies a missing
field would get them filled in out of tidiness. When the SAVED rule carries
a check, the stamp shows with Still true / No longer true beside it. The
stamp reads the stored value, not the draft: an unsaved edit to the textarea
has not been run against anything.
SWEEP PANE — its own surface, not a filter on the rule list. That list can
only ever show one topic of one rulebook, and a rule that has gone false
belongs to no one rulebook; filtering it would under-report, which is the
failure this whole surface exists to catch. Reached from the rulebook list,
below the rulebooks, because that is where you go to look at rules.
RULE ROWS — a chip only on rules carrying a check, so its presence is the
signal. PROJECT RULES TAB — the check shows beside `why` when a rule has
one, read-only: that tab is the project's view of what binds it.
NO AGE-GRADED COLOUR anywhere, deliberately. The sweep is already ordered by
urgency, so a red/amber ramp would restate the ordering AND require an
invented "stale after N days" threshold — a magic number nobody could defend
and the first thing to go out of date. --fs-overdue is error red and reserved
for a broken promise like a missed due date; a verification age is not one,
and colouring it that way makes a rule someone just wrote look broken. Only
"never" is marked, because it is categorically different from a date rather
than a worse one — and it is marked by weight, not hue.
An empty sweep says "Nothing to check", not nothing: good news must not read
as a broken page.
Two chips (tier, then verification) turned out byte-identical, so .rule-chip
moves to rules-shared.css and snippet #2906 is updated to match rather than
left describing a file that has moved on. Its header comment counted the
panes it served; that count went stale the moment a fourth arrived, so it no
longer counts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
34 lines
1.2 KiB
CSS
34 lines
1.2 KiB
CSS
/* Shared by the rules panes (RulebookListPane, RuleListPane,
|
|
RulebookDetailPane, RuleSweepPane): the pane surface, its heading, and the
|
|
title chip. Counting them in this comment went stale the first time a
|
|
fourth was added, so it no longer does. Load with
|
|
<style src="@/assets/rules-shared.css" /> beside the component's own
|
|
scoped block; never restate these there (#2903, milestone 299). */
|
|
.pane {
|
|
background: var(--fs-surface-hover);
|
|
padding: 1rem;
|
|
overflow-y: auto;
|
|
}
|
|
.pane header h2 {
|
|
font-family: Fraunces, serif;
|
|
font-style: italic;
|
|
margin: 0 0 0.5rem 0;
|
|
}
|
|
.form-buttons { display: flex; gap: 0.5rem; }
|
|
|
|
/* A small marker beside a rule's title. Two of these appeared within one
|
|
milestone (tier, then verification) and were byte-identical; a third would
|
|
have drifted. The pane's italic serif title is inherited by anything inside
|
|
it, so the chip resets family and style explicitly. */
|
|
.rule-chip {
|
|
margin-left: 0.4rem;
|
|
font-family: var(--fs-font-body);
|
|
font-style: normal;
|
|
font-size: 0.62rem;
|
|
color: var(--fs-text-secondary);
|
|
background: var(--fs-surface-raised);
|
|
border-radius: var(--fs-radius-pill);
|
|
padding: 0.05rem 0.4rem;
|
|
vertical-align: middle;
|
|
}
|