timothy
fba5233caf
168 records -> docs/decisions/records/<area>/<topic>.md (163 active, 23 dirs) and docs/decisions/archive/<area>/<topic>.md (5 archived). The filename IS the key, so one-active-record-per-key becomes a filesystem property rather than a validator check, and supersession becomes a `git mv`. WHY: the monolith was a concurrency problem before an aesthetic one. A 3,900-line append target made parallel sessions collide -- PR #605 and PR #614 both hit append-vs-append conflicts during routine rebases, and hand-resolving those inside the corpus is exactly the operation the rationale-rewrite guard exists to police. HOW IT IS VERIFIED: a ~170-file diff cannot be meaningfully read, so correctness does not rest on reading it. The parser was taught BOTH formats first, so the body-diff guard parses the old form at the merge-base and the new form at head -- the migration validates itself, no bypass. The proof is a field-level equivalence harness: 168 records before and after, zero lost, zero gained, zero field mismatches, zero rationale bodies differing. Reviewers should scrutinise the harness; it is the actual evidence. What measuring caught that reading would not have: - ~500 lines sit OUTSIDE any record -- decisions.md's lifecycle schema and each topic file's preamble, mostly the only copy. Source files are kept and stripped, never deleted. They also cannot be filed per-area: topic files hold several areas and 4 of 23 areas span several files. - Archive discovery was a non-recursive glob; after the split it found ZERO archived records, surfacing as four bogus "supersedes points to unknown key" errors rather than an obvious failure. - ~32 live docs point into the corpus BY DATE, which the split dangles. Each stripped file now ends with a generated "Records formerly in this file" index, which also rescues the identical breadcrumbs in old issue comments. - decisions.md's "In this file:" list was 97 same-file anchor bullets that the split makes WRONG, not merely stale. Dropped; the generated index replaces them with links that resolve. The equivalence harness now runs against a checked-in FIXTURE, not the live corpus. The earlier version migrated the real tree, which made it a one-shot: the moment the migration landed there was nothing left to move and the tests failed for reasons unrelated to the code. A fixture keeps them testing the SCRIPT rather than the repo's current state. Keys preserved verbatim, warts included: `sched` (12) and `scheduling` (1) remain two directories for one concept. Renaming a key is not a move -- it changes identity, breaks the equivalence proof, and invalidates MemPalace's per-key drawers. Taxonomy normalisation is separate work. refs #610
2.8 KiB
key, title, status, since, supersedes, superseded-by, rule, signals, mechanics
| key | title | status | since | supersedes | superseded-by | rule | signals | mechanics |
|---|---|---|---|---|---|---|---|---|
| rulebuilder.relative-date-macros | 2026-07-23 — Relative-date rule builder operators are a frontend-only mapping onto existing Lucene macros (#435) | active | 2026-07-23 | none | none | The visual rule builder's `inLast`/`notInLast` date operators compile to/parse from the pre-existing `CustomMultiFieldQueryParser` macros `released_inthelast`/`released_notinthelast` and `added_inthelast`/`added_notinthelast`, value form `"<n> day|week|month|year"`; there is no backend change. | relative date operator, inLast, notInLast, inthelast macro, released_inthelast, added_inthelast, date unit picker, rule builder relative dates · paths: `web/src/builder/rules/dateMacro.ts`, `web/src/builder/rules/compile.ts`, `web/src/builder/rules/parse.ts`, `web/src/builder/rules/types.ts`, `web/src/builder/rules/validation.ts` · issues: #435, #176, #438 | `dateMacro.ts` (`compileRelative`/`parseRelative`, `OP_TO_SUFFIX`/`SUFFIX_TO_OP`, `RELATIVE_SYNTHETIC`); spa-conventions.md §12 |
released_inthelast/added_inthelast (+ their notinthelast negations) already existed in
CustomMultiFieldQueryParser as free-text macro fields before the rule builder could reach them — they
were only usable by typing raw Lucene. #435 exposes them as first-class builder operators without touching
the parser: release_date/added_date gain inLast/notInLast alongside the existing before/after/
between, backed by a numeric-value input plus a day|week|month|year unit picker (types.ts's unit?: DateUnit). dateMacro.ts is the single seam — a small field↔macro-prefix table (release_date↔released,
added_date↔added) plus the inLast/notInLast ↔ inthelast/notinthelast suffix maps — that compile.ts
delegates to for these two fields and parse.ts recognizes via RELATIVE_SYNTHETIC before falling into the
generic field:value grammar. Validation (ruleError in validation.ts) requires the value to parse as a
positive integer; a non-numeric or non-positive value is a builder-side error, never sent to the server.
Frontend-only because the macros are the query-string wire format, not a new query kind. The compiled
query for release_date inLast "7 day" is literally released_inthelast:"7 day" — the same string a user
could type by hand — so nothing downstream (search index, SmartCollection storage, Auto-Tune) needs to know
the rule builder exists. This keeps rulebuilder.relative-date-macros symmetric with
spa.smartcollection-rule-builder's "compile-only, no new stored AST" stance (#176): a relative-date rule is
just another point in the same closed grammar subset, proven by the same compile→parse round-trip discipline
(dateMacro.test.ts, and the property test in roundtrip.test.ts, #438) rather than a special case.