feat(description): an STS section's description is its own first spec point
K3-19 c. The NISO-STS reader records, per titled <sec>, the FIRST <p> of its FIRST direct-child <sec sec-type="spec"> as `OutlineMark.description`. The plan entry carries it (`description`, only where the source has one, so every other row's plan keeps its bytes), `parse_segmentation_plan` refuses an empty, multi-line or non-string value, and the door writes it as the concept's `description` after the gate has seen it: it is document text persisted outside the body the gate screens, so it is kept only on the non-blocking floor and as the sanitized text. SPEC SS 4.1 makes `description` RECOMMENDED and sets no length, in SS 4.1, SS 8 or SS 11. The limit is ours and structural -- one paragraph, whole -- because a cut inside it writes a sentence the source never wrote. Measured on R761: 2 026 of 2 761 titled sections carry a direct-child spec point; the first <p> runs 17 / 109 / 273 / 521 / 942 characters (min / median / p90 / p99 / max). A section with none gets no key; nothing is derived from the title. A stated `--frontmatter description=...` replaces it. The extracted text does not move: the description is read beside it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
0dbc331b76
commit
de7849e35b
6 changed files with 96 additions and 4 deletions
|
|
@ -640,7 +640,10 @@ bundle:
|
|||
the `sources` title from `<doc-number>` + `<year>`, then `<title-wrap>`,
|
||||
then the file name, whichever is the first that can be written verbatim.
|
||||
Stated more than once, or claimed by a second document in the same run, a
|
||||
declared name is not used and the file name stays.
|
||||
declared name is not used and the file name stays. Each titled section's
|
||||
`description` is its own first spec point — the first `<p>` of its first
|
||||
direct-child `<sec sec-type="spec">`, whole — and a section with none gets
|
||||
no `description` at all; nothing is derived from the title.
|
||||
The drop directory is walked **recursively**, in sorted relative-path order:
|
||||
a file at any depth is ingested and records its path relative to the inbox
|
||||
root as its `source_file`, while dot-directories and a bundle directory
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue