[fadi-dev-1]

Workstream

D211, its row in docs/governance/workstreams.md. It carries a decision, PDR-0023, Proposed: the decider who assigned the defect chose option B. Approving this pull request accepts it. A maintainer then turns its status to Accepted, here or in a follow-up.

What it changes

On a project, C10 warned that a decision was due at cycle 07's closure. Its success criterion cited the record it amends, with the amendment's date. Another criterion, due before a date months later, was named due at the closure its amendment date reached. PDR-0020 §6 reads any YYYY-MM-DD of the criterion as a due date, and infers nothing from prose. Telling an amendment's date from a deadline therefore needed a decision, not a bug fix.

PDR-0023 amends PDR-0020 §1 and §6 on that one point. Only a date written in bold, alone between the markers (**2027-01-31**), is a due date. The forms already show the due date that way: observed before <YYYY-MM-DD>. The rule still infers nothing from prose:

Criterion	Before	After
before **2026-10-01**	due	due
(PDR-0004, amended 2026-10-01)	due	not read
amended 2026-10-01 … before **2026-10-18** (closure 2026-10-17)	due, by the amendment	not due yet
before 2026-10-01	due	not read
**before 2026-10-01**	due	not read
cycle 03, 03-the-window	due	due (unchanged)

• fitness/plan.py: DAY matches **YYYY-MM-DD** only; the C10 docstrings say it.
• fitness/plan.py: a criterion with no bold date and no cycle named, holding a plain date a closure reached and no reading after it, gets a C10 warning: no due date C10 can read … put the due date in bold, YYYY-MM-DD. A date written amended YYYY-MM-DD stays quiet. A criterion left with no due date C10 can read is reported; a plain date beside a bold due date is no longer read, by design; PDR-0023 (Decision 4), RULES.md C10 and 06-decisions.md §5 say it.
• docs/pdr/0023-…: the decision, with its options (A, before/by, rejected because it infers prose; C, keep the rule, rejected because every author pays). The PDR index lists it, and 0020's row says it is amended. PDR-0020 itself is not rewritten.
• The PDR and ADR forms' comment, 06-decisions.md §5, framing.md's closure, RULES.md C10 and the glossary say it.

What a project receives

• Engine: C10 reads only bold dates.
• Skeleton: nstack update merges five pages and the two forms.
• Effect on existing records: a criterion whose due date is plain stops being named at closures until its author bolds it. Amendment and reference dates stop being named. Nothing turns red: C10 is a warning.
• Migration: the version's paragraph has to say to bold the due date in existing records. To be written in the version pull request.

Definition of Done

• The behaviour is covered by a test that failed before — committed first, seen red (P5)
• Every failure names the rule, the place and the action (P6) — the warning's text is unchanged
• uv run bash platform/tests/run.sh green, on a committed tree
• uv run nstack fitness green
• Affected documentation updated, diagrams and legends included; no dead reference
• The workstream's row updated in the register; its plan deleted, if it had one
• Brought current with main as the last thing before opening
• No private project named, no path of a workstation, no link into an assistant's session

Summary

DONE

• PDR-0023, proposed: only a bold date is a criterion's due date. It amends PDR-0020 §1 and §6.
• C10 reads only **YYYY-MM-DD** in the success criterion section.
• The forms, handbook, playbook, RULES.md and glossary say it. PDR index updated; register row D211.

VERIFIED

• Tests committed first, in their own commit (34c050d). Against the old rule, four cases failed:
  • an amendment date alone;
  • an amendment date reached, beside a bold date not reached;
  • a plain date;
  • a bold run holding words.
• After the fix, all 162 tests of test_plan.py pass. Among them: a bold date alone is due, and an amendment date beside a bold date that was reached is due once.
• The existing C10 cases now write their due dates in bold.
• uv run bash platform/tests/run.sh: 1269 passed, Platform tests: OK.
• uv run nstack fitness --root .: compliant. nstack pr-scope: inside the review budget.

ASSUMED

• "Written in bold" means **…** around the date alone. __…__ and a bold run holding words are not read, so the rule stays exact.

NOT VERIFIED

• Not run against the project that exposed it; the tests reproduce the case.
• Not checked by an independent verifier.

RISKS

• A project whose records write due dates plain loses those warnings until the dates are bolded. The migration paragraph has to say it.
• This repository's own records keep plain dates (e.g. By 2027-03-31). They are outside C10 (PDR-0020, Out of scope), so nothing is lost. Bolding them would touch about thirty records for no effect, and was left for a maintainer to decide.
• Register rows: D210 (D210 — claim never takes an earlier cycle's start branch, and a renewal starts one #380) adds its row at the same place, so whichever merges second settles a one-line conflict.

🤖 Generated with Claude Code