The direct answer
Keep the exact parent tree, submodule path and recorded commit together, then establish the separately admitted dependency content and source policy. A verified parent release does not supply that complete association by itself. Missing content or mismatched metadata leaves dependency review incomplete; it does not authorize a repair fetch or checkout.
Give the dependency its own review row
A fictional assistant explains an already admitted text-library release. Its parent release record identifies commit P-A and tree T-A. The proposed review includes a dependency at vendor/text-kit. Calling the parent “signed” leaves a practical question: which dependency content is actually included in the explanation?
Select exactly one direct submodule and no nested submodules. All labels below are invented references, not object identifiers, verified signatures or observed files. Every worksheet and eight cards are PROPOSED_UNRUN. No candidate Git command, repository, object, configuration, checkout, remote, signature or model operation occurred.
The existing signed-tag guide establishes a different parent association. This worksheet starts after that admission and does not repeat its verification or grant permission to execute the release.
Understand what the parent records
The gitsubmodules manual describes a submodule with its own history. The superproject tracks a gitlink at a path; that entry names the commit expected for the submodule. Its .gitmodules entry associates the name and path and supplies configuration hints. The manual also describes deinitialized submodules with tracking metadata but no working directory.
Our proposed receipt therefore separates an expected dependency identity from available reviewed content. Do not replace the missing-content question with a screenshot of the parent release label. Nor should a later working directory silently become the evidence for a previously selected commit.
Preserve entry evidence without inventing a reader
The git-ls-tree manual documents tree listings with mode, object type, object name and path. Path selection can depend on the working directory and matching patterns; its full-tree option addresses the working-directory scope. These documented fields motivate the receipt, not a command recipe or output parser.
A separately supported reader must bind complete, unambiguous entry evidence to T-A, retaining full object identity and the declared path. A convenient name-only listing cannot satisfy our richer record. Actual object validation, supported formats, trusted configuration, bounded capture and immutable handoff remain unknown here. An ambiguous or incomplete result blocks admission instead of inviting an improvised revision expression.
Separate versioned metadata from source permission
The gitmodules manual distinguishes a subsection’s name from its required unique relative path. Its required URL can be absolute or relative to the superproject’s origin. Separately, gitsubmodules places command-line and repository configuration above the versioned file in its configuration discussion.
Our application policy records the exact versioned association, the independently approved source and relevant effective configuration as separate evidence. A URL in repository content is a proposed location, not a grant to contact it. This worksheet supplies no URL resolver, configuration-precedence implementation or retrieval workflow. Unknown source selection stays unresolved even if the recorded dependency identity appears familiar.
Build one useful association sheet
The ordinary positive is a small library whose single dependency is already available in a separately admitted complete store. The proposed sheet binds these symbolic fields before another stage considers a bounded review:
| Field | Teaching entry | Independent evidence required |
|---|---|---|
| Parent | P-A / T-A | Exact admitted parent association |
| Dependency edge | vendor/text-kit → S-A | Complete entry evidence from T-A |
| Versioned metadata | Name N-A, same path, location U-A | Metadata from the selected parent revision |
| Source and content | Approved source I-A; admitted content S-A | Separate provenance, completeness and rights |
| Next step | Explain selected library text | Explicit coverage and current permission |
U-A and I-A are intentionally different kinds of field: a declared location and an approved source policy. The sheet requires supported agreement between them, not string equality as a trust rule. A content digest copied from an untrusted proposal cannot establish an independently accepted baseline.
Actual stores, complete parent/dependency inventories, reader integrity, configuration, source provenance, current rights and same-object handoff are unimplemented and unknown. Missing required evidence blocks the positive. Establishing those prerequisites would make only the selected association eligible for later review, not prove harmless code.
Walk eight inert association cards
| Condition | Proposed disposition |
|---|---|
| 1. P-A/T-A, declared edge, S-A, admitted content and source policy agree; all prerequisites hold | Conditionally admit that association for separate bounded review. |
| 2. Parent evidence matches, but the edge identifies S-B | Hold the changed dependency; retain the discrepancy. |
| 3. Parent metadata exists but admitted S-A content is missing | Mark dependency coverage incomplete; no repair fetch. |
| 4. Name, path or declared location differs from the receipt | Reconcile the full association before reuse. |
| 5. Relevant effective configuration is different or unknown | Do not assume the versioned location settles source selection. |
| 6. A current branch tip or later checkout replaces S-A | Reject substitution under this fixed-identity plan. |
| 7. Nested dependency, unsupported entry or partial reader result appears | Outside the selected profile; no automatic recursion. |
| 8. Association agrees but content, rights or next operation fails admission | Deny that separate step; provenance supplies no override. |
State coverage before handing text to a model
The existing diff profile excludes submodules. This worksheet changes none of its restrictions and supplies no missing comparison engine. A future dependency review needs its own admitted scope and evidence; “parent reviewed” must not become “all dependency content reviewed.”
The actual manuals showed latest-profile Git 2.56.0; their last-change labels were 2.52.0, 2.54.0 and 2.42.0 respectively. No installed Git, object format or available store was inspected. No checkout, build, installation, licensing assessment or dependency behavior was established.
Boundary is prelaunch with planned request-path checks, not a shipped Git dependency-review service. Its separate local mock-policy evidence does not validate this worksheet or establish a customer outcome.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.