Spec Studio

Serialization preserves authored entry order

spec:extraction.open-section-orderBusiness Rule · storyready floor ready

Packs: pack:self-hosting-v1

Design: no design entries · no pinned declarations · no decisions

Findings: no errors, no warnings

specs/extraction/open-section-order.sdp.md

No open questions and no blocking questions; implementation binding present, verifier binding present, and expected-outcome oracle none.

Integer-like keys are refused rather than carried in an ordered list: JavaScript orders integer-like object keys before all others, so a plain object keeps authored order only when no key is integer-like.

Intent
problem
Sorting entries by code unit loses the author's sequence and grouping.
outcome
Carry the authored order of open-section entries and model terms through the serialized graph and the Design Review's key order.
Rule
rule line 18 · specs/extraction/open-section-order.sdp.md:18
The entry order of design, ui, and model terms is authored content. Extraction keeps it, the serialized graph emits it, the Design Review's entry list follows it for open sections, and the Model table follows it for terms.
rule line 19 · specs/extraction/open-section-order.sdp.md:19
Authored order is a function of the committed source, so two derivations of one commit stay byte-identical. What is given up is invariance under permutation: two carriers that author the same entries in different orders derive different graph bytes, and parity for these sections means the same entries in the same order.
rule.integerLikeKey line 20 · specs/extraction/open-section-order.sdp.md:20
A key is integer-like when it matches ^(0|[1-9][0-9]*)$; design, ui and model.terms refuse such keys in every carrier that carries those sections.

no example exercises it

rule line 21 · specs/extraction/open-section-order.sdp.md:21
The Markdown carrier refuses an integer-like Model term with the structure finding model terms must not be integer-like and drops the carrier. Its lower-camel Design and UI keys cannot be integer-like. Gherkin carries no open section.
rule line 22 · specs/extraction/open-section-order.sdp.md:22
The TypeScript carrier reads identifier and string names as their text and numeric names as JavaScript's string form of the number, so 1e3 becomes "1000", 0x10 becomes "16", and 0.0000001 becomes "1e-7".
rule line 23 · specs/extraction/open-section-order.sdp.md:23
The TypeScript carrier refuses each integer-like property, method, getter or setter with one extract/unrecognized-property error regardless of value, with the message property "<key>" is refused: integer-like keys are not accepted in design, ui, or model terms. Only that member drops; the Spec and other keys remain.
rule line 24 · specs/extraction/open-section-order.sdp.md:24
A non-integer numeric name such as 1.5 drops as a non-static name.
rule line 25 · specs/extraction/open-section-order.sdp.md:25
With integer-like keys refused, a plain object keeps insertion order, so the representation stays an object and no field shape changes. Authored key order is part of the graph contract. The derived graph establishes it, so the reader, the serialized graph, and the Design Review agree. In design and ui the section's own description, its leading prose, comes first, then every other key in authored order. model.terms keeps pure authored order, and a term named description is an ordinary term, because the Model section's prose lives at model.description.
rule line 26 · specs/extraction/open-section-order.sdp.md:26
The reader exposes authored order as the key order of a Spec context's sections.design, sections.ui, and sections.model.terms; entry search rows follow it, and no reader method is added.
rule line 27 · specs/extraction/open-section-order.sdp.md:27
Rendering open-section entries as a list follows the authored-entry-order decision; this Spec supplies the order the list follows.

9 unkeyed rules.

Verification

Verifier bindings

  • test:protocol.open-section-order · verifies serialized authored entry order · anchored · test anchor binding present · test/graph-schema.test.ts:27

    External run evidence from test/graph-schema.test.ts

    Test anchors: test:protocol.claim-taxonomy, test:protocol.open-section-order. Specs verified by those bindings: spec:extraction.claim-taxonomy, spec:extraction.open-section-order.

    Run 1: external run evidence from vitest 4.1.10

    Build: CI 391 · Branch: cursor/media-plan-and-articles-09b1 · Commit: 076cd4f1f85640d8236e5cca1bffffa68ab79a33 · Start: 2026-10-31T15:32:20.471Z · Stop: 2026-10-31T15:34:02.073Z

    NameSuiteResultDuration
    serializes authored entry order with description first and schema 0.12.0graph schemapassed2.17 ms
    gives the reader, the serialized graph, and the Design Review one entry ordergraph schemapassed31.66 ms
    serializes question text, optional blocking and optional key in canonical ordergraph schemapassed0.6 ms
    inherits the Pack's declared claim for membership and keeps binding claims apartgraph schemapassed74.94 ms
    exports the graph schema contractsgraph schemapassed0.36 ms
Design view

Requirement drawing

  • Declared verifying examples: no declared verifying example.
Requirement drawing for spec:extraction.open-section-order
The diagram as text
  • spec:extraction.open-section-order: Serialization preserves authored entry order · declared Spec
  • spec:extraction.derive-graph: Carrier reification derives the one graph · declared Spec
  • impl:protocol.open-section-order: preserves authored open-section and model-term order and Pack field order · anchored code · src/extract/serialize.ts:105
  • test:protocol.open-section-order: verifies serialized authored entry order · anchored test binding · binding present · test/graph-schema.test.ts:27
  • spec:extraction.open-section-order refines spec:extraction.derive-graph · declared
  • impl:protocol.open-section-order satisfies spec:extraction.open-section-order · anchored
  • test:protocol.open-section-order verifies spec:extraction.open-section-order · anchored
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred and chosen syntax: requirementDiagram; exact refines, satisfies and verifies, with claim words in nodes and per-edge comments.

Decisions

No decision record named.

Runtime
  • component:protocol.extract · the carrier and source pipeline · src/extract/index.ts:192 · layer application · context protocol

    Uses

    • component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol
    • component:protocol.model · the authored contracts and stable ids · src/model/anchors.ts:100 · layer domain · context protocol
    • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
    • component:protocol.validate · one finding currency and ordered checks · src/validate/validators.ts:72 · layer domain · context protocol
  • impl:protocol.open-section-order · preserves authored open-section and model-term order and Pack field order · src/extract/serialize.ts:105

    Component: component:protocol.extract · the carrier and source pipeline · src/extract/index.ts:192 · layer application · context protocol

    Uses

    None.

Runtime observation: not tracked.

Evidence

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

Impact
Relations of spec:extraction.open-section-order
The diagram as text
  • spec:decisions.authored-entry-order: The Design Review renders open-section entries as a list
  • spec:extraction.derive-graph: Carrier reification derives the one graph
  • spec:extraction.open-section-order: Serialization preserves authored entry order
  • spec:extraction.open-section-order refines spec:extraction.derive-graph · declared
  • spec:decisions.authored-entry-order dependsOn spec:extraction.open-section-order · declared
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: flowchart. Chosen syntax: labelled flowchart, preserving exact relations, claims and folds.

Rests on

Rested on by

Distance 1

Distance 2

Distance 3

Distance 4

Distance 5

Distance 6

Distance 7

Distance 8

Relations

Relation and directionOther endClaimReasonExercised keys
refines · outgoingCarrier reification derives the one graph
spec:extraction.derive-graph · resolves		declaredNoneNone
dependsOn · incomingThe Design Review renders open-section entries as a list
spec:decisions.authored-entry-order · resolves		declaredNoneNone

Bindings

Implementation binding: present

  • impl:protocol.open-section-order · preserves authored open-section and model-term order and Pack field order · src/extract/serialize.ts:105 · role codec · component component:protocol.extract · layer application · context protocol

Design reference: none

Verifier binding: present

  • test:protocol.open-section-order · verifies serialized authored entry order · anchored · test/graph-schema.test.ts:27 · test anchor

Expected-outcome oracle: none

Runtime observation: not tracked.

Run results: not recorded in the graph.

Findings

None.

Composing (0)

Composing needs the script.