family.py and shape_materialize.py: the helpers that ask a template's own YAML reader and validator about a manifest's values exist twice, for project.yaml (#314) and for family.yaml (#397) #470

Lane: openreposhape-5 (openRepoShape-5)

(lane openRepoShape-5, 2026-10-12T20:39:32Z)

Found by lane 5 while landing #397 (#307). Not claimed.

#314 (landed as 3ef059c) and #397 (head abb27e6, cut from c7c02fa, so before #314) each ask the new file's OWN YAML reader (repo_shape.parse_yaml) and its OWN validator about the values a tool is about to write, before anything is created:

• scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314, for the assembly root's project.yaml and scripts/validate-manifest.py, from scaffold-project.py and adopt-project.py (scaffold-project.py writes --id and --tracking-branch into project.yaml unquoted, so --id null or --id true scaffolds a project whose first bootstrap fails manifest-id, and --tracking-branch true, 007 or null puts the clone's legs on True, 7 or main with no upstream: #181's defect on the scaffold side, beside #225 #258, adopt-project.py and scaffold-project.py accept values the new project's own validate-manifest.py refuses (a blank --elected-by or --reference, --elected-on 2026-W41-6 or 20261011 on Python 3.11+, --org test+org, a plan's visibility: secret), so adoption verified or a scaffold exit 0 is followed by a failed first bootstrap; and plan admits a 251-255-character --project that check refuses #261).
• family.py: init asks the holder's reader and validate-family.py about family.yaml before creating anything, --dry-run too, so --id null, --tracking-branch true, a blank --created-by and --created-on 20261011 are refused (#307) #397, for the holder's family.yaml and scripts/validate-family.py, from family.py init (family.py init exits 0 and pushes a holder its own validate-family.py refuses for --id null, --created-by ' ', --created-on 20261011 or --name 'Contoso Group', and puts --tracking-branch true on a branch its manifest reads back as True #307).

#397's code comment (scripts/family.py:1028-1033 at abb27e6) and its description said that whichever of the two landed second would unify them. #314 landed first, and #397 leaves the two as they are. This issue is the unification.

The helpers that do the same job. Line numbers are at 3ef059c for scripts/shape_materialize.py and at abb27e6 for scripts/family.py.

The three tools each also hold a table that names a placeholder by the flag a person typed: MANIFEST_FLAGS at scaffold-project.py :104 and adopt-project.py :1814 (3ef059c), and at scripts/family.py :1052 (abb27e6).

What unifying them would mean. One definition of each helper above, called by scaffold-project.py, adopt-project.py and family.py, with what differs (the last column) supplied by each caller or kept by the tool that owns it. This issue proposes no design beyond that.

What it must not change.

• Any refusal code or word the tools print today. The codes are scaffold-manifest-misread, scaffold-manifest-invalid, adopt-manifest-misread, adopt-manifest-invalid, the plan-manifest-invalid FINDING, manifest-validator-unusable, family-manifest-misread, family-manifest-invalid and family-validator-unusable. tests/test_scaffold_manifest_values.py and tests/test_adopt_manifest_values.py (3ef059c) and tests/test_family_init_values.py (abb27e6) assert them.
• When the questions are asked. Before a work directory, a remote or a repository exists, and under --dry-run alike. A misread is said first and alone, and the validator's finding about it is not said after it.
• How the validator is asked. It is LOADED from its template and never re-implemented, no bytecode is written into the template tree, sys.path and sys.dont_write_bytecode are put back, and a validator that cannot be asked is a refusal, not a traceback and not a pass. The family's extra checks (SystemExit, a Report with no findings, a finding that is not text) have no counterpart in manifest_invalid, which catches Exception only. Whether the assembly root takes them is a change of behaviour to decide, and not a consequence of unifying.
• Where the helpers live. scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 put its helpers in scripts/shape_materialize.py, and not in scripts/repo_shape.py or a validator, because those are shape copies digested in every project's contracts/shape-pin.yaml: a change to either puts an upstream-changed row in front of every project (the comment at scripts/shape_materialize.py :2183-2188, 3ef059c). No copied file and no template changes with this.
• That the questions stay template-relative. Each asks the TEMPLATE, line by line, and never a list of which lines are written bare, so once a placeholder is 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) the misread question refuses nothing with no edit. scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 holds that with test_quoting_the_template_would_make_the_refusal_go_away in tests/test_scaffold_manifest_values.py, and family.py: init asks the holder's reader and validate-family.py about family.yaml before creating anything, --dry-run too, so --id null, --tracking-branch true, a blank --created-by and --created-on 20261011 are refused (#307) #397 with test_a_quoted_value_is_held_as_typed and the quoted-template tests after it in tests/test_family_init_values.py, which run over a copy of the template whose placeholder is forced quoted.

The comment at scripts/family.py :1028-1033 (abb27e6) that says the second to land unifies them is stale now that #314 landed first, and goes with the unification.

Refs #314, #261, #397, #307.