Today —
$ sed -n '104,107p' action/README.md
**The plan is these inputs.** Tracking with a different `start-week` — or a
different `background` — compares against a different plan and reports nonsense
confidently. The report prints the placement it used on its second line; if that
ever changes, so did your plan.
The consumer copied the sentence verbatim (contribution-art/README.md:43). Here is the whole markdown report for that consumer's plan — what the action publishes:
### Heart · 2026
**Cannot be drawn cleanly** — 1 day is inside the letters already lit, and nothing takes those away.
| | |
| --- | --- |
| letters bright | 0 of 56 |
| still owing | 56 days · 1,978 contributions |
| a letter day costs | 36 (peak 141 on 2026-08-19) |
| today | letter day — 0 of 36 there, 36 to go |
| tomorrow | inside the letters — keep it dark |
| already past | 2 days · 34 contributions, back-dating only |
The second line is blank, in both formats. grep -niE "start[- ]week|column|week 35" over the markdown and over the 25-line text report returns nothing. Changing the placement only moves the numbers:
-- start-week 34 -- **Cannot be drawn cleanly** — 5 days are inside the letters already lit, …
-- start-week 35 -- **Cannot be drawn cleanly** — 1 day is inside the letters already lit, …
-- start-week 36 -- **On track** — 2,016 contributions to go.
Two things sharpen it. --format text does print both frozen inputs for a text plan with overdue days, inside the back-dating command it suggests (… --year 2026 --start-week 6 --top 1 --backfill …) — but that block is not printed for a picture, which is what the consumer tracks, and the markdown carries them for neither kind. And the markdown does print a --start-week N number when a better placement exists ( `--start-week 4` would leave 17 holes instead of 25.) — the suggested week, not the one in use, so a reader following the documented check can read week 4 off a report whose plan is week 6.
The values exist in --format json ({"start_week":35,"columns":11}); action.yml declares neither among its 20 named outputs.
Why it is worth fixing — this is the only guard the project offers against the one failure it itself calls silent and confident, and the only consumer adopted it as its stated safety net. contribution-art posts a report to its tracking issue on every run; if anyone edits start-week: "35" in track.yml — and mossaic's own report invites it — the next report simply has different numbers, and the numbers in this report legitimately change every day. A changed plan is indistinguishable from a normal day's drift. The reader following the documented procedure checks the second line, finds the verdict sentence there, and concludes nothing moved. The drawing preview's header does not rescue it either: it is byte-identical across start-weeks 34, 35 and 36, and the action never runs that path.
Fix — the sentence is false today, so something has to move. The cheapest honest fix is to delete it from action/README.md and from contribution-art's copy, but that leaves the guard unbuilt. Prefer one of:
- Put the placement in the tracking header the way the drawing preview already does —
### Heart · 2026 · week 35, 11 columns in markdown, Heart · 2026 · week 35, 11 columns — tracking vyncint in text. start_week and columns are already on Report.
- Add
start-week and columns to action.yml's outputs, wired from .start_week and .columns, so a workflow can assert its plan rather than read for it.
Either alone makes the documented check possible; both together let a consumer turn the guard into a test, which is what it should have been.
Done when — tracking the same picture at start-week 34, 35 and 36 produces three reports whose headers differ, in both --format text and --format markdown; and action/README.md's "second line" sentence names a line that actually carries the placement, or is gone, with contribution-art's copy following.
Today —
The consumer copied the sentence verbatim (contribution-art/README.md:43). Here is the whole markdown report for that consumer's plan — what the action publishes:
The second line is blank, in both formats.
grep -niE "start[- ]week|column|week 35"over the markdown and over the 25-line text report returns nothing. Changing the placement only moves the numbers:Two things sharpen it.
--format textdoes print both frozen inputs for a text plan with overdue days, inside the back-dating command it suggests (… --year 2026 --start-week 6 --top 1 --backfill …) — but that block is not printed for a picture, which is what the consumer tracks, and the markdown carries them for neither kind. And the markdown does print a--start-week Nnumber when a better placement exists (`--start-week 4` would leave 17 holes instead of 25.) — the suggested week, not the one in use, so a reader following the documented check can read week 4 off a report whose plan is week 6.The values exist in
--format json({"start_week":35,"columns":11}); action.yml declares neither among its 20 named outputs.Why it is worth fixing — this is the only guard the project offers against the one failure it itself calls silent and confident, and the only consumer adopted it as its stated safety net. contribution-art posts a report to its tracking issue on every run; if anyone edits
start-week: "35"in track.yml — and mossaic's own report invites it — the next report simply has different numbers, and the numbers in this report legitimately change every day. A changed plan is indistinguishable from a normal day's drift. The reader following the documented procedure checks the second line, finds the verdict sentence there, and concludes nothing moved. The drawing preview's header does not rescue it either: it is byte-identical across start-weeks 34, 35 and 36, and the action never runs that path.Fix — the sentence is false today, so something has to move. The cheapest honest fix is to delete it from action/README.md and from contribution-art's copy, but that leaves the guard unbuilt. Prefer one of:
### Heart · 2026 · week 35, 11 columnsin markdown,Heart · 2026 · week 35, 11 columns — tracking vyncintin text.start_weekandcolumnsare already onReport.start-weekandcolumnsto action.yml's outputs, wired from.start_weekand.columns, so a workflow can assert its plan rather than read for it.Either alone makes the documented check possible; both together let a consumer turn the guard into a test, which is what it should have been.
Done when — tracking the same picture at start-week 34, 35 and 36 produces three reports whose headers differ, in both
--format textand--format markdown; and action/README.md's "second line" sentence names a line that actually carries the placement, or is gone, with contribution-art's copy following.