[MAJOR] §12: No release workflow — build artifacts not stored or published

[mvillmow]

Evidence

.github/workflows/ (no release.yml), .github/workflows/_required.yml:106-119

Description

The build job in _required.yml runs python -m build --no-isolation and verifies the build succeeds, but the resulting artifacts are not uploaded, tagged, or published. There is no workflow triggered by a tag or release event. Publishing to PyPI or GitHub Releases requires manual steps that are undocumented.

Part of #92

[mvillmow]

Implementation Plan

Now I have full ground truth. Issue #176 is OPEN but most of its scope landed in PR #260. The remaining gaps are: (1) the workflow has never run end-to-end (no v*.*.* tag exists), (2) PyPI Trusted Publisher is still unconfigured per docs/RELEASING.md:74, (3) the "advisory" note at docs/RELEASING.md:14-16 is now outdated since deps-version-sync in _required.yml:322-368 enforces it, and (4) a release-time dry-run / sanity check would close the loop.

Let me produce the implementation plan focused on these closure items.

Implementation Plan

Objective

Issue #176 asks for a tag-triggered release workflow that builds, attaches, and publishes Telemachy distribution artifacts. PR #260 (merged 2026-06-03 as fa93375) created .github/workflows/release.yml with four jobs (verify-version, build, github-release, pypi-publish) and updated docs/RELEASING.md + CHANGELOG.md. The issue is still OPEN because the workflow has never been exercised end-to-end (no v*.*.* tag exists in the repo), the PyPI Trusted Publisher is still unconfigured per docs/RELEASING.md:73-78, and one factual claim in the runbook is now stale. This plan closes those gaps and validates issue #176's acceptance criteria so it can be closed.

Approach

Three concrete decisions, each grounded in verified repo state:

• Do not modify the release workflow YAML. release.yml:1-152 already covers every requirement in the issue body: it triggers on v*.*.* tag pushes (release.yml:4-6), uploads dist/* via actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 (release.yml:82-87), attaches artifacts to a GitHub Release via softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda # v3.0.0 (release.yml:122-131), and publishes to PyPI via OIDC pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0 (release.yml:147-151). All third-party actions are already SHA-pinned with version comments, matching _required.yml's convention.
• Correct the stale "advisory" claim in docs/RELEASING.md:14-16. That paragraph says the version sync check is "currently advisory; the release author is responsible for keeping them aligned." This is false: _required.yml:322-368 (the deps-version-sync job in Required Checks) parses pyproject.toml and src/telemachy/__init__.py with ast.literal_eval and exits 1 on mismatch. It is enforced on every PR, not advisory. Leaving the docs wrong creates a footgun for the first releaser.
• Validate with workflow_dispatch is not possible — release.yml:3-6 has no workflow_dispatch: trigger. Adding one is out of scope (it would mean writing publish-skip guards on every job). Instead, validation runs through the existing _required.yml schema-validation job (_required.yml:311-320, which check-jsonschemas every .github/workflows/*.yml against https://json.schemastore.org/github-workflow) plus a one-shot static dry-run script that simulates the version-equality check locally. A real end-to-end exercise requires a real tag push and is appropriately the "first real release" task, not a CI verification step.

Closure flow: docs PR fixing the stale claim → operator configures PyPI Trusted Publisher per docs/RELEASING.md:71-78 (one-time, manual on pypi.org — cannot be automated) → comment on issue #176 listing each acceptance bullet with the file:line that satisfies it → close issue #176 with a reference to PR #260 and this closure PR.

Files to Create

None.

Files to Modify

docs/RELEASING.md

Replace the stale "advisory" sentence at docs/RELEASING.md:14-16 with the truth about deps-version-sync. Current text:

All three must agree at release time. A CI sync check exists (see
`workflows/`) but is currently advisory; the release author is responsible
for keeping them aligned.

Replace with:

All three must agree at release time. The `deps-version-sync` job in
`.github/workflows/_required.yml` enforces this on every PR by parsing
`pyproject.toml` and `src/telemachy/__init__.py` with `ast.literal_eval`
and exiting non-zero on mismatch. The release workflow's
`verify-version` job (`.github/workflows/release.yml:16-62`) is the
second-layer check that the pushed tag agrees with both sources.

No other edits to RELEASING.md are needed — steps 1-8 (docs/RELEASING.md:38-62) already describe the automated flow and recovery rule ("do not delete and re-push the tag").

CHANGELOG.md

Under [Unreleased] → ### Added, replace the existing PR-#260 line at CHANGELOG.md:10-15 to add the issue-number anchor. Current:

- Release workflow (`.github/workflows/release.yml`) that builds
  sdist+wheel on `v*.*.*` tag pushes, cross-checks the tag against
  `pyproject.toml` and `__init__.py`, attaches artifacts to a GitHub
  Release with changelog-derived notes, and publishes to PyPI via
  Trusted Publishing. Closes #153; part of #92.

Replace with (add #176 to the closes list):

- Release workflow (`.github/workflows/release.yml`) that builds
  sdist+wheel on `v*.*.*` tag pushes, cross-checks the tag against
  `pyproject.toml` and `__init__.py`, attaches artifacts to a GitHub
  Release with changelog-derived notes, and publishes to PyPI via
  Trusted Publishing. Closes #153, #176; part of #92.

No _required.yml, release.yml, pyproject.toml, pixi.toml, src/telemachy/__init__.py, or CLAUDE.md changes.

Implementation Order

1. Create a branch (e.g. fix/176-releasing-docs).
2. Edit docs/RELEASING.md:14-16 per the snippet above.
3. Edit CHANGELOG.md:10-15 to add #176 to the closes list.
4. Run local lint: pixi run yamllint -c .yamllint.yaml docs/RELEASING.md CHANGELOG.md (the project's yamllint config skips Markdown — this is a no-op safety net) and markdownlint-cli2 docs/RELEASING.md CHANGELOG.md if available locally; otherwise rely on the markdownlint Required Check (_required.yml:85-98).
5. Commit: docs: correct version-sync claim in RELEASING; tag #176 in CHANGELOG.
6. Open PR titled docs: close out release-workflow runbook for #176. Body: link to PR feat: add release workflow for GitHub and PyPI publishing #260, list acceptance criteria from issue [MAJOR] §12: No release workflow — build artifacts not stored or published #176 with the file:line that satisfies each, and note the one remaining external action (PyPI Trusted Publisher config).
7. After merge: operator performs the one-time PyPI Trusted Publisher config on https://pypi.org/manage/account/publishing/ per docs/RELEASING.md:71-78 — project telemachy, owner HomericIntelligence, repo ProjectTelemachy, workflow filename release.yml, environment pypi. This step cannot be automated from inside the repo.
8. Post a closure comment on issue [MAJOR] §12: No release workflow — build artifacts not stored or published #176 quoting the four acceptance bullets and the satisfying evidence, then close the issue with Closes #176 in the PR description (auto-close on merge).

Verification

One runnable command per acceptance criterion from the issue body. Each is runnable against the current main:

# Acceptance 1: a workflow IS triggered by a tag/release event
grep -nE "^\s*tags:" .github/workflows/release.yml
# expected: line 5 ("    tags:") followed by "      - 'v*.*.*'" — proves tag-trigger exists

# Acceptance 2: build artifacts ARE uploaded (not just verified)
grep -nE "actions/upload-artifact" .github/workflows/release.yml
# expected: line 82 — proves upload step exists, retention 90d, if-no-files-found: error

# Acceptance 3: artifacts ARE attached to a GitHub Release
grep -nE "softprops/action-gh-release|files: dist/\*" .github/workflows/release.yml
# expected: lines 123 + 128 — proves Release creation with dist/* attached

# Acceptance 4: artifacts ARE published to PyPI (no longer "manual undocumented")
grep -nE "pypa/gh-action-pypi-publish|id-token: write" .github/workflows/release.yml
# expected: lines 140 + 148 — proves OIDC trusted publishing step

# Acceptance 5: the publish path IS documented (no longer "undocumented")
grep -nE "Trusted Publisher|pypi-publish" docs/RELEASING.md
# expected: matches in the "Automation" section (post-edit) — proves the runbook covers it

# Required-check coverage of the new workflow file itself:
pixi run python -c "
import pathlib, re
p = pathlib.Path('.github/workflows/_required.yml').read_text()
assert 'schema-validation' in p, 'schema-validation job missing'
assert 'find .github/workflows -name' in p, 'glob does not pick up release.yml'
print('OK: release.yml is covered by schema-validation on every PR')
"

# Static dry-run of the verify-version job's tag-vs-version logic, exercised against the current tree:
pixi run python - <<'PY'
import tomllib, ast, pathlib
pp = tomllib.load(open("pyproject.toml","rb"))["project"]["version"]
init = pathlib.Path("src/telemachy/__init__.py").read_text()
init_ver = next(
    ast.literal_eval(n.value)
    for n in ast.walk(ast.parse(init))
    if isinstance(n, ast.Assign)
    for t in n.targets
    if isinstance(t, ast.Name) and t.id == "__version__"
)
assert pp == init_ver, f"pyproject ({pp}) != __init__ ({init_ver})"
print(f"OK: pyproject.toml and __init__.py agree on {pp}; tag v{pp} would pass verify-version")
PY

# Lint + markdownlint sanity on the modified docs:
pixi run yamllint -c .yamllint.yaml .
# markdownlint runs as a Required Check on PR; reproduce locally if needed:
# npx markdownlint-cli2 --config .markdownlint.yaml docs/RELEASING.md CHANGELOG.md

The first real end-to-end verification (live tag push, OIDC token exchange, PyPI upload, GH Release creation) is the next genuine release — appropriately a "first real release" event, not a PR-time check. Per docs/RELEASING.md:74-76, until the operator configures the Trusted Publisher, the pypi-publish job will fail loudly with an OIDC error — the intended fail-loud behaviour, not a silent skip.

Skills Used

Invoked during planning:

• Bash + Read to verify ground truth: release.yml already exists at 152 lines covering all four acceptance criteria; PR feat: add release workflow for GitHub and PyPI publishing #260 merged 2026-06-03 (fa93375); CHANGELOG.md already has the PR-feat: add release workflow for GitHub and PyPI publishing #260 line under [Unreleased]; docs/RELEASING.md exists with the manual-runbook claim now stale; deps-version-sync at _required.yml:322-368 does enforce literal-__version__; the issue is still OPEN with no closedAt timestamp.
• gh issue view 176 + gh pr view 260 to confirm the open/merged states and detect that the prior plan had already been implemented.

Referenced from team knowledge base (Prior Learnings, audit remediation plan Wave 9):

• Wave 9 ("Release & Distribution") consolidates findings [minor] §6: No release or deployment workflow #98, [minor] §6: No release or deployment workflow #119, [MINOR] §6: No release or deployment workflow #153, [MINOR] §6: No release or deployment workflow #216, [major] §12: No release workflow — build artifacts not stored or published #114, [MAJOR] §12: No release workflow — build artifacts not stored or published #176. PR feat: add release workflow for GitHub and PyPI publishing #260 closed [MINOR] §6: No release or deployment workflow #153; this plan closes [MAJOR] §12: No release workflow — build artifacts not stored or published #176.

Skills for the implementer:

• hephaestus:verification — run the seven verification commands above before merging.
• commit-commands:commit-push-pr — land the docs change.
• hephaestus:finish-branch — post the closure comment and confirm the issue auto-closes on PR merge.

Changes from Review

N/A — initial plan against current main. The prior plan comment on this issue (committed 2026-05-17) was written before PR #260 merged. Its review verdict was "GO" but it described work to be done; that work is now done in main as of fa93375. This is not a revision of the prior plan — it is a fresh plan against the post-PR-#260 reality, focused on closing the issue rather than re-implementing what already exists.

---

Final review verdict (from strict review loop)

Now I have enough ground truth to conduct the review. Let me analyze each dimension.

---

Review: Implementation Plan for Issue #176

Issue Requirements

The issue states:

1. No workflow triggered by tag/release event
2. Build artifacts not uploaded or attached to releases
3. Publishing to PyPI or GitHub Releases requires manual steps that are undocumented

Dimension 1: Requirements Alignment

Verified: release.yml exists and already satisfies all four acceptance criteria the plan claims:

• Tag trigger at line 5 (v*.*.*) ✓
• Artifact upload at line 82 (actions/upload-artifact) ✓
• GitHub Release attachment at line 122-131 (softprops/action-gh-release) ✓
• PyPI publish at line 147-151 (pypa/gh-action-pypi-publish) ✓

The plan correctly identifies that PR #260 implemented all core requirements and the remaining gaps are closure items. However, the issue body has no formal acceptance criteria list — the plan reasonably derives them from the description. No silently dropped criteria.

Minor concern: The issue title says "[MAJOR]" severity but the plan frames its remaining work as docs cleanup. This is an accurate reading — the major finding is resolved, what remains is documentation accuracy. The plan should state this framing explicitly to justify closing the issue rather than leaving it open for a "real end-to-end exercise."

Dimension 2: Plan Completeness

The plan covers:

• Design: the release workflow is already built — no new design needed ✓
• Implementation: two targeted file edits (docs and CHANGELOG) ✓
• Tests/Verification: seven concrete grep/python commands ✓
• Rollback: the two changes are doc-only and trivially reversible ✓

Finding (minor): The plan omits that the docs/RELEASING.md:14-16 stale claim actually uses the path workflows/ (not .github/workflows/) in its text — the plan's replacement text is more accurate, but the diff context is important. The plan acknowledges this in "Learnings captured" but marks it as an assumption, not a risk to address before landing.

Dimension 3: Concreteness

The plan names specific files, line numbers, and exact text replacements for both changes. The verification commands are runnable as-is. The implementation order is step-by-step. This dimension is strong.

One concreteness gap: The plan says "CHANGELOG.md:10-15" for the edit location but the actual CHANGELOG shows the PR-#260 entry at lines 12-16. This is a minor line-number discrepancy that could cause a reviewer or implementer to look at the wrong lines.

Dimension 4: Risk Surface

The plan explicitly identifies:

• No workflow YAML changes (low risk) ✓
• Doc-only changes are trivially reversible ✓
• PyPI Trusted Publisher is manual and irreversible from inside the repo ✓
• The plan explicitly flags the OIDC fail-loud behavior ✓

Finding (moderate): The plan's "Learnings captured" section flags four unverified assumptions but does not convert them into plan steps or mitigations. Specifically:

• "Assumption: release.yml:14-16 lines still match stale text" — I verified this: the stale text IS at docs/RELEASING.md:14-16 exactly matching the plan's quoted text. This assumption is valid. But the plan asks the implementer to trust an unverified claim.
• "Assumption: _required.yml:322-368 range" — I verified: deps-version-sync starts at line 322. The plan's description of its enforcement logic is accurate (uses ast.literal_eval, exits non-zero on mismatch). The range claimed (322-368) roughly matches the actual job.

The "Learnings" are listed as warnings to the implementer but aren't resolved in the plan steps. A better plan would close these loops or explicitly mark them as "confirmed."

Dimension 5: Verification Plan

Seven concrete verification commands are provided, each tied to a specific acceptance criterion. This is the strongest dimension of the plan.

Finding (minor): The schema-validation verification command uses pixi run python -c with inline Python that asserts string presence in _required.yml. This verifies that the job name and glob exist, but doesn't actually run the schema validator against release.yml to confirm it's valid — it just checks the text of the CI file. A real schema validation would require pixi run check-jsonschema. The plan acknowledges this is what the Required Check does, but the local simulation is weaker than claimed.

Dimension 6: Stage Handoff

The plan provides:

• Exact text to replace (before/after quoted) ✓
• Exact file paths and approximate line numbers ✓
• Implementation order (8 steps) ✓
• Skills to invoke ✓
• Post-merge operator action documented ✓

Finding (minor): Step 4's lint command (pixi run yamllint ... docs/RELEASING.md CHANGELOG.md) acknowledges yamllint skips Markdown — making this step a no-op safety net. The plan should either remove this phantom step or clarify it only serves as a config check. It does mention "rely on the markdownlint Required Check" as the real gate, which is acceptable.

Software Engineering Principles

P1 (KISS): The plan is appropriately minimal. It explicitly refuses to add workflow_dispatch: or modify release.yml. Two targeted text edits. No KISS violation.

P2 (YAGNI): All planned changes directly address closing issue #176's remaining gaps. No scope creep. No YAGNI violation.

P3 (TDD): This is a docs-only change. No tests are applicable. The verification commands are the appropriate substitute. Acceptable.

P4 (DRY): N/A for two doc edits.

P5 (SOLID): N/A for doc changes.

P6 (Modularity): N/A.

P7 (POLA): The plan's replacement text for RELEASING.md is more accurate than the stale text. The replacement correctly describes enforcement behavior rather than "advisory." No POLA violation.

Critical Finding: Issue Closure Justification

The plan claims issue #176 should be closed after this docs PR. However, the issue body's evidence says "no release.yml" — which is now false (release.yml exists). The plan correctly identifies that the MAJOR finding is resolved. But the plan does not address whether the issue title's severity classification ("MAJOR §12") has a formal acceptance test. The plan assumes the issue can be closed via Closes #176 in the PR body — this is reasonable but should be stated as explicit plan step (it is mentioned in step 8, which is adequate).

Summary of Findings

Major findings: None.

Moderate findings:

• The "Learnings captured" section lists 4 unverified assumptions that remain unresolved in the plan steps. Two of them I verified as correct, but the plan doesn't mark them resolved — leaving implementer doubt. This is a documentation quality issue, not a blocking correctness issue.

Minor findings:

1. CHANGELOG line-number citation (10-15 vs actual 12-16) is slightly wrong.
2. The pixi run yamllint step on Markdown is a no-op by design — could confuse the implementer.
3. The schema-validation verification command checks text presence rather than running the actual validator.
4. The plan's framing of "first real end-to-end verification requires a real tag push" is correct but could more explicitly address why this doesn't block issue closure (since the issue's requirement is that automation exists, not that it has run).

Overall Assessment

The plan is accurate about repo state (verified), correctly identifies the minimal remaining work, provides concrete and runnable verification commands, and makes sound engineering decisions (no unnecessary workflow changes). The "Learnings captured" section is intellectually honest but should have been converted into confirmed facts rather than open assumptions. All findings are minor to moderate. The plan is implementable as written.

Grade: B
Verdict: GO

---

Generated by Claude Code Planner (strict review loop)

[mvillmow]

🔍 Plan Review

Now I have enough ground truth to conduct the review. Let me analyze each dimension.

---

Review: Implementation Plan for Issue #176

Issue Requirements

The issue states:

1. No workflow triggered by tag/release event
2. Build artifacts not uploaded or attached to releases
3. Publishing to PyPI or GitHub Releases requires manual steps that are undocumented

Dimension 1: Requirements Alignment

Verified: release.yml exists and already satisfies all four acceptance criteria the plan claims:

• Tag trigger at line 5 (v*.*.*) ✓
• Artifact upload at line 82 (actions/upload-artifact) ✓
• GitHub Release attachment at line 122-131 (softprops/action-gh-release) ✓
• PyPI publish at line 147-151 (pypa/gh-action-pypi-publish) ✓

The plan correctly identifies that PR #260 implemented all core requirements and the remaining gaps are closure items. However, the issue body has no formal acceptance criteria list — the plan reasonably derives them from the description. No silently dropped criteria.

Minor concern: The issue title says "[MAJOR]" severity but the plan frames its remaining work as docs cleanup. This is an accurate reading — the major finding is resolved, what remains is documentation accuracy. The plan should state this framing explicitly to justify closing the issue rather than leaving it open for a "real end-to-end exercise."

Dimension 2: Plan Completeness

The plan covers:

• Design: the release workflow is already built — no new design needed ✓
• Implementation: two targeted file edits (docs and CHANGELOG) ✓
• Tests/Verification: seven concrete grep/python commands ✓
• Rollback: the two changes are doc-only and trivially reversible ✓

Finding (minor): The plan omits that the docs/RELEASING.md:14-16 stale claim actually uses the path workflows/ (not .github/workflows/) in its text — the plan's replacement text is more accurate, but the diff context is important. The plan acknowledges this in "Learnings captured" but marks it as an assumption, not a risk to address before landing.

Dimension 3: Concreteness

The plan names specific files, line numbers, and exact text replacements for both changes. The verification commands are runnable as-is. The implementation order is step-by-step. This dimension is strong.

One concreteness gap: The plan says "CHANGELOG.md:10-15" for the edit location but the actual CHANGELOG shows the PR-#260 entry at lines 12-16. This is a minor line-number discrepancy that could cause a reviewer or implementer to look at the wrong lines.

Dimension 4: Risk Surface

The plan explicitly identifies:

• No workflow YAML changes (low risk) ✓
• Doc-only changes are trivially reversible ✓
• PyPI Trusted Publisher is manual and irreversible from inside the repo ✓
• The plan explicitly flags the OIDC fail-loud behavior ✓

Finding (moderate): The plan's "Learnings captured" section flags four unverified assumptions but does not convert them into plan steps or mitigations. Specifically:

• "Assumption: release.yml:14-16 lines still match stale text" — I verified this: the stale text IS at docs/RELEASING.md:14-16 exactly matching the plan's quoted text. This assumption is valid. But the plan asks the implementer to trust an unverified claim.
• "Assumption: _required.yml:322-368 range" — I verified: deps-version-sync starts at line 322. The plan's description of its enforcement logic is accurate (uses ast.literal_eval, exits non-zero on mismatch). The range claimed (322-368) roughly matches the actual job.

The "Learnings" are listed as warnings to the implementer but aren't resolved in the plan steps. A better plan would close these loops or explicitly mark them as "confirmed."

Dimension 5: Verification Plan

Seven concrete verification commands are provided, each tied to a specific acceptance criterion. This is the strongest dimension of the plan.

Finding (minor): The schema-validation verification command uses pixi run python -c with inline Python that asserts string presence in _required.yml. This verifies that the job name and glob exist, but doesn't actually run the schema validator against release.yml to confirm it's valid — it just checks the text of the CI file. A real schema validation would require pixi run check-jsonschema. The plan acknowledges this is what the Required Check does, but the local simulation is weaker than claimed.

Dimension 6: Stage Handoff

The plan provides:

• Exact text to replace (before/after quoted) ✓
• Exact file paths and approximate line numbers ✓
• Implementation order (8 steps) ✓
• Skills to invoke ✓
• Post-merge operator action documented ✓

Finding (minor): Step 4's lint command (pixi run yamllint ... docs/RELEASING.md CHANGELOG.md) acknowledges yamllint skips Markdown — making this step a no-op safety net. The plan should either remove this phantom step or clarify it only serves as a config check. It does mention "rely on the markdownlint Required Check" as the real gate, which is acceptable.

Software Engineering Principles

P1 (KISS): The plan is appropriately minimal. It explicitly refuses to add workflow_dispatch: or modify release.yml. Two targeted text edits. No KISS violation.

P2 (YAGNI): All planned changes directly address closing issue #176's remaining gaps. No scope creep. No YAGNI violation.

P3 (TDD): This is a docs-only change. No tests are applicable. The verification commands are the appropriate substitute. Acceptable.

P4 (DRY): N/A for two doc edits.

P5 (SOLID): N/A for doc changes.

P6 (Modularity): N/A.

P7 (POLA): The plan's replacement text for RELEASING.md is more accurate than the stale text. The replacement correctly describes enforcement behavior rather than "advisory." No POLA violation.

Critical Finding: Issue Closure Justification

The plan claims issue #176 should be closed after this docs PR. However, the issue body's evidence says "no release.yml" — which is now false (release.yml exists). The plan correctly identifies that the MAJOR finding is resolved. But the plan does not address whether the issue title's severity classification ("MAJOR §12") has a formal acceptance test. The plan assumes the issue can be closed via Closes #176 in the PR body — this is reasonable but should be stated as explicit plan step (it is mentioned in step 8, which is adequate).

Summary of Findings

Major findings: None.

Moderate findings:

• The "Learnings captured" section lists 4 unverified assumptions that remain unresolved in the plan steps. Two of them I verified as correct, but the plan doesn't mark them resolved — leaving implementer doubt. This is a documentation quality issue, not a blocking correctness issue.

Minor findings:

1. CHANGELOG line-number citation (10-15 vs actual 12-16) is slightly wrong.
2. The pixi run yamllint step on Markdown is a no-op by design — could confuse the implementer.
3. The schema-validation verification command checks text presence rather than running the actual validator.
4. The plan's framing of "first real end-to-end verification requires a real tag push" is correct but could more explicitly address why this doesn't block issue closure (since the issue's requirement is that automation exists, not that it has run).

Overall Assessment

The plan is accurate about repo state (verified), correctly identifies the minimal remaining work, provides concrete and runnable verification commands, and makes sound engineering decisions (no unnecessary workflow changes). The "Learnings captured" section is intellectually honest but should have been converted into confirmed facts rather than open assumptions. All findings are minor to moderate. The plan is implementable as written.

Grade: B
Verdict: GO