§17 progress reports become a labelled-row block — v1.47 - #27
§17 progress reports become a labelled-row block — v1.47#27UnbreakableMJ wants to merge 1 commit into
Conversation
Rewrite §17.1 and §17.2. Every tracked track now gets its own row, its own 20-cell bar, and its own percentage, in a fixed order: milestone rows M0..Mn ascending, then MVP, then TODO, then PLAN, then PRD. TODO and PLAN are new tracks — the old three-line format had no way to report against a plan document or a task list, so work driven by either was reported against a PRD that did not exist. Only applicable rows are emitted; padding the block with fabricated 0% rows is forbidden, since a reader cannot tell a placeholder from a genuine zero. §17.2 now defines two cell styles. Milestone/TODO/PLAN/PRD rows use U+2588/U+2591 with tight brackets; the MVP row keeps U+25B0/U+25B1 with one space inside each bracket. MVP is the headline figure and the rows around it are its inputs, so it stays findable in a stack of otherwise identical bars. The bracket padding is what holds the columns aligned — the MVP label field is one character narrower and each bracket one character wider, so every bar cell and percentage digit shares a column. Cell count is specified for the first time: the percentage scaled to twenty cells and rounded, with twenty filled only at exactly 100% and zero filled only at exactly 0%. Rounding 99% up to a complete bar reports work as finished that is not. §17.3 cadence is unchanged. §16's §17 checklist bullet is rewritten to match. Regenerated the .md companion.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d04df7f87
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @documentencoding UTF-8 | ||
| @documentlanguage en | ||
| @settitle The Steelbore Standard 1.46 | ||
| @settitle The Steelbore Standard 1.47 |
There was a problem hiding this comment.
This reviewed commit has no gpgsig or SSH-signature header, so when pushed to GitHub it cannot show as Verified. Recreate it with a valid cryptographic signature before landing it; the repository explicitly makes this mandatory for assistant-generated commits as well.
AGENTS.md reference: AGENTS.md:L90-L90
Useful? React with 👍 / 👎.
| The percentage is right-aligned so its @code{%} sign lands in the same column on every row — two spaces after the closing bracket on the tight-bracket rows, one on the @code{MVP} row. That difference is exactly what the padded brackets buy. | ||
| @item | ||
| The separator never drops below one space. At 100% the @code{MVP} row keeps its single space and its percentage therefore sits one column right — the only value at which the two row types do not align, and preferable to a bracket abutting a digit. |
There was a problem hiding this comment.
For a block mixing one- and two-digit percentages, the fixed separators specified here do not right-align the % signs: on a tight row, two spaces put 5% and 60% in different columns. At 100%, the stated fixed gaps instead put both row types in the same column, contradicting the following MVP exception. A renderer therefore cannot satisfy all these normative rules; specify a target percentage column and digit-dependent padding instead.
Useful? React with 👍 / 👎.
|
|
||
| @strong{Row order} is fixed: milestone rows @code{M0}…@code{Mn} in ascending order, then @code{MVP}, then @code{TODO}, then @code{PLAN}, then @code{PRD}. | ||
|
|
||
| @strong{Only applicable rows are emitted.} The milestone rows match the milestones the plan actually defines — there is no fixed count, and @code{M0}–@code{M4} in the template above is an illustration, not a required set. @code{TODO}, @code{PLAN}, and @code{PRD} each appear only when the task is driven by such an artifact. @code{MVP} is always present. A row is never padded in at 0% to fill out the block: a fabricated track reports progress against nothing and misrepresents the work. |
There was a problem hiding this comment.
When a task is driven only by a TODO list, this new rule says to emit a TODO row, but the unchanged chapter introduction at line 3729 requires reporting only for work based on a PRD or project plan. Consequently TODO-only work remains outside §17 and never has to emit the row introduced for that case; include TODO-driven tasks in the chapter’s triggering scope.
Useful? React with 👍 / 👎.
1 participant
Rewrites §17.1 and §17.2. Requested format change: every tracked track gets its own row, its own 20-cell bar, and its own percentage.
What changed and why
The old format packed everything into three dense lines, and only the PRD total ever got a bar — the least granular figure got the only visual, while milestones and MVP were bare integers.
TODOandPLANare new tracks. The old format could not report against a plan document or a task list at all, so work driven by either was reported against a PRD that did not exist.TODO/PLAN/PRDappear only when the task is driven by such an artifact;MVPis always present. Padding with fabricated 0% rows is forbidden — a reader cannot tell a placeholder from a genuine zero.MVPkeeps▰/▱with one space inside each bracket; every other row uses█/░with tight brackets. MVP is the headline figure and the rows around it are its inputs, so it stays findable in a stack of otherwise identical bars.Specified beyond the requested sample
Two glyph sets forced the column math to be pinned down:
MVPfollowed by[and a space; bars occupy columns 8–27 on both.%lands in the same column — two spaces after]on tight rows, one onMVP. That asymmetry is exactly what the bracket padding buys.MVProw cannot both keep a separator and hold the column, so its percentage sits one column right. Stated as a rule rather than left as an accident.Verification
makeinfo --no-split— 0 errors, 0 warnings.mdcompanion regenerated via the DocBook routereuse lintclean (the one flagged file is an untracked local.docx, absent from CI's checkout)§17.3's cadence is unchanged. §16's §17 checklist bullet rewritten to match.
Stacked
PR 2 of 2 — based on #26 (v1.46), merge after it. The Construct-side sync is a separate PR at the same version; Scrubber's implementation is Spacecraft-Software/Scrubber#1.
🤖 Generated with Claude Code