scaffold-project.py: --pin 007@<commit> exits 0 and scaffolds a root whose own validate-pins.py refuses entry 7, because neutral_product_pins: entries (and the pin file's product:) are written bare #516

Lane: openreposhape-2 (openRepoShape-2)

(lane openRepoShape-2, 2026-10-13T13:55Z) Filed on Brett Heap's word: his answer "File as v1.0.0 issue" to this lane's question on L2-11, 2026-10-13T13:52Z. It replaces checklist item L2-11 on #459, its parent. The adopt side is #514, fixed in PR #515.

The state. A person scaffolds with scaffold-project.py --pin <product>@<commit> --pin-source <clone>, and YAML reads the product name as a number: 007, 2026 or 1.5.

What happens. This was probed on main 631f087 with local bare remotes and a stub gh.

• The scaffold accepts 007 and exits 0.
• project.yaml gets neutral_product_pins: then - 007 (scaffold-project.py:1259-1260). The project's YAML reader reads that back as [7].
• In a recursive clone of the root, validate-manifest.py --root . says manifest ok. validate-pins.py --root . exits 1 with FINDING neutral-pin-entry-malformed: project.yaml neutral_product_pins entry 7 is not a non-empty product name. The root's validate.yml runs it, so the new project's first CI run is red.
• The neutral pin template writes product: {{PIN_PRODUCT}} bare (templates/assembly-root/contracts/neutral-product-pin.yaml:30), so contracts/007-pin.yaml says product: 007, which also reads back as 7.
  • No reader compares that field today (validate-pins.py reads source_repository), so it fails nothing yet.
  • Both the scaffold and adopt render this template.
• The openGlass control passes both validators.

Why v1.0.0. Brett Heap's word. A scaffold that exits 0 makes a root that its own validator refuses. Only a product name that reads as a number reaches it, but --pin accepts one.

Fix direction.

• Render each neutral_product_pins: entry so the project's reader gets back the text given. adopt-project.py: execute writes each neutral_product_pins: entry so it reads back as the text plan recorded, so plan --pin 007@<commit> no longer says adoption verified over a root whose own validate-pins.py refuses entry 7 (#514) #515 does this for adopt with _neutral_product_pins and _neutral_pin_entry. The scaffold has double_quoted (templates/assembly-root/project.yaml and the two leg pins write eight text placeholders bare (id, elected_on, visibility, tracking_branch, the two leg paths and submodule_paths), so a checked value YAML reads as another type (007, 2026, true, null) is misread by the project or refused by the tool; quoting them reads every one back exactly and lets numeric branch names adopt #259).
• Plain names such as openGlass stay byte for byte as they are.
• Write the pin file's product: so that it too reads back as the text, for both tools.
• Leave every other line byte for byte as it is.

How to test.

• For 007, 2026, 1.5 and openGlass, scaffold with --pin <name>@<commit> --pin-source <a local clone> into local bare remotes.
• In a recursive clone of the root, assert:
  • validate-pins.py --root . and validate-manifest.py --root . exit 0;
  • neutral_product_pins: reads back as the text given;
  • contracts/<name>-pin.yaml's product: reads back as the text given.
• The first three cases are red on main.
• The pin template is shared, so adopt's --pin tests run too.

Evidence: in opensoft/brett-wip, handoffs/xFactory/attachments/lane-openRepoShape-2/impl514-adopt-neutral-pins-quoted/tools/scaffold-pin.sh and tools/w514-scaffold-probe-631f087.log. See also PR #515's body, "The scaffold side".

Related:

• adopt-project.py: execute writes each neutral_product_pins: entry bare, so plan --pin 007@<commit> says adoption verified over a root whose own validate-pins.py refuses entry 7 #514 and PR adopt-project.py: execute writes each neutral_product_pins: entry so it reads back as the text plan recorded, so plan --pin 007@<commit> no longer says adoption verified over a root whose own validate-pins.py refuses entry 7 (#514) #515: the adopt side.
• templates: project.yaml, the leg pins and family.yaml quote their text placeholders, so --id 007, --tracking-branch 2026, --spec-path true or --org null read back as typed, and family.py add quotes a member id alike (#259) #395: quoted the templates' text placeholders, but not these.
• templates/assembly-root/project.yaml and the two leg pins write eight text placeholders bare (id, elected_on, visibility, tracking_branch, the two leg paths and submodule_paths), so a checked value YAML reads as another type (007, 2026, true, null) is misread by the project or refused by the tool; quoting them reads every one back exactly and lets numeric branch names adopt #259: double_quoted.
• Tracking: setup, scaffold, family and the shared helpers, creating projects and families #459: the parent.