[documentation-writing-alignment] Verify source-bound TestData adoption guidance #578

Context and request

Readers need a verified record of the required adoption actions for the fixed test-secret inputs replaced by TestData. This residual scope is split from #560 so settled entry-page wording can proceed without deleting or rewriting required compatibility guidance.

Evidence and source boundary

At 64ffb1d87f86bd5d487891fdb140b78385a00531, calling-the-workflow.md, blob 8e18d7e18025b68a1abd318c115719607d3683c3, retains a breaking-change section, the exact old input list, the required TestData.secrets mapping, and executable YAML. The documentation model keeps evergreen usage separate from source-bound release adoption records, but removing this section before the adoption record is verified would lose required actions.

The integration coordinator explicitly does not release that section for relocation, deletion, or compatibility rewriting. The exact owning decision remains with #535 and #537. #322 concerns a different secrets: inherit request and does not establish this source-bound adoption record.

Acceptance criteria

• Identify the actual consumed baseline and target source/version for the fixed-input transition.
• Locate and verify the source-bound release record that carries every required adoption action, or retain an explicit evidence gap.
• Obtain the exact caller/release-authoring owner decision before changing the guide's migration section.
• Preserve the exact input names, environment names, TestData schema, executable examples, compatibility conditions, required ordering, and normative force.
• Evergreen guidance describes supported usage without losing necessary adoption actions. No invented publication, migration, or enforcement claim is introduced.
• Any resulting documentation PR is focused and remains in draft; the work does not change framework behavior or publish a release.

Technical decisions and readiness

This Task owns documentation/source-record reconciliation only. It does not implement the older inheritance request, change the caller interface, create an unverified release record, or wake/amend existing proposal branches. The governing sources are the pinned Documentation Model and PR Format. The source/record verification and exact owner handback are the readiness gate; this is not a blanket hold on other prose.

Implementation plan

• Trace the source transition and retained adoption instructions before editing; capture the baseline-to-target evidence.
• Verify the actual immutable release record and owner decision, including every required action and its applicability.
• Establish a before/after preservation check for input names, schema, examples, compatibility, and instruction completeness.
• Make only the approved guide/record correction in one focused draft PR or its explicitly verified owning record path.
• Run existing relevant Markdown/link/site checks and record source-bound acceptance evidence; do not claim a migration or publication that did not occur.

Read-only release-record findings

The transition is commit 364ddd65e7de2c04bc1b526974fd1a0f5097b123, the #365 merge. Current v6.0.0 resolves to that exact commit; current v5.5.9 resolves to 8b7553757b50e2e265a12bc3b0bab2078c5b3fea. The two immutable source trees show the seven fixed workflow-call inputs before the transition and optional TestData afterward.

The published v6.0.0 record, release ID 351262274, contains all seven old names and the required move into TestData.secrets. It was published at 2026-07-09T02:18:03Z. This is a relevant record, not proof that its adoption examples are sufficient or correct:

• Its first workflow example still references workflow.yml@v5 while describing the v6 transition. Applicability of that example is not established by the current v6 source identity.
• Anonymous, non-executing PyYAML parsing of the exact first YAML fence produces a TestData string with five line breaks. That contradicts the record's own single-line-after-folding guidance. No secrets are resolved and no workflow, mask behavior or publication is executed by this probe.
• The current release API reports immutable: false, target_commitish: main and no assets. The current version-tag identity has been verified; original publication-to-source provenance has not been established by those fields alone.

The v7.0.0 record instead covers the GitHub App/explicit publication-credential transition. The v8.0.3 record discusses Pester and an Expose-TestData boundary; neither replaces the v6 fixed-input adoption decision.

The exact #535 / #537 owner decision and source-bound record reconciliation remain required before deleting, relocating or rewriting the protected guide section. This evidence does not authorize editing historical records or adopting an unverified example. All current guide text, release bodies, tags, producer code and lifecycle settings remain unchanged.