Fix stale frontmatter hash in design-decision-gate.lock.yml

[Copilot]

TestHashConsistencyAcrossLockFiles was failing in CI because design-decision-gate.lock.yml contained a stale frontmatter_hash — the source workflow had model: claude-sonnet-4-6 added to its frontmatter, the lock file was recompiled locally, but the updated lock file was never committed.

Change

• Commit the recompiled design-decision-gate.lock.yml with the correct frontmatter_hash and body_hash matching the current markdown source.

[github-actions]

✅ PR Code Quality Reviewer completed the code quality review.

[github-actions]

✅ Test Quality Sentinel completed test quality analysis.

No test files were added or modified in this PR. Test Quality Sentinel skipped. Only .github/workflows/design-decision-gate.lock.yml was changed (stale frontmatter hash fix).

[github-actions]

🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅

[Copilot]

Pull request overview

This PR updates the generated workflow lock file for design-decision-gate to bring its embedded gh-aw-metadata hashes back in sync with the current markdown source workflow frontmatter (including the newly specified Claude model), unblocking CI (TestHashConsistencyAcrossLockFiles).

Changes:

• Recompiled .github/workflows/design-decision-gate.lock.yml so frontmatter_hash and body_hash match the current .md source.
• Captured the configured agent model (claude-sonnet-4-6) in the lock metadata and the generated run-info environment (GH_AW_INFO_MODEL).

Show a summary per file

File	Description
.github/workflows/design-decision-gate.lock.yml	Regenerates the lock metadata and run-info env to reflect the current source workflow frontmatter and content hashes.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 0

[github-actions]

✅ Design Decision Gate 🏗️ completed the design decision gate check.

No ADR enforcement needed: PR #41390 does not have the 'implementation' label and has 0 new lines of code in business logic directories (threshold: 100).

[github-actions]

Skills-Based Review 🧠

Applied /diagnose — the fix correctly addresses the root cause and the existing regression test confirms it.

📋 Analysis Summary

Root Cause Verified

• The source workflow (.github/workflows/design-decision-gate.md) explicitly declares model: claude-sonnet-4-6 at line 25.
• The lock file was recompiled from that source, producing the correct frontmatter_hash and body_hash.
• The GH_AW_INFO_MODEL change from a dynamic variable fallback chain to "claude-sonnet-4-6" is the expected compiled output when a model is pinned in the source frontmatter.

Regression Safety

• TestHashConsistencyAcrossLockFiles already existed and caught this drift — good CI hygiene.
• No new test needed; the existing test is the regression guard.

Positive Highlights

• ✅ PR description clearly traces the root cause
• ✅ Single-file, minimal-scope fix — no collateral changes
• ✅ Auto-generated lock file updated via the correct recompile workflow

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · 33.4 AIC · ⌖ 7.34 AIC · ⊞ 6.5K

[github-actions]

✅ Correct fix, no blocking issues

This correctly recompiles the lock file from the actual committed markdown source, which had model: claude-sonnet-4-6 in its frontmatter but was never re-locked after that change.

What was verified

• frontmatter_hash change — expected; the frontmatter now includes model: claude-sonnet-4-6, which was missing from the stale hash.
• body_hash change — the lock file was introduced in fbee0bc compiled from an older markdown version; the new hash reflects the current body. One inline comment notes the test gap here.
• agent_model: "claude-sonnet-4-6" added to metadata — correct output for a model-pinned compilation.
• GH_AW_INFO_MODEL hardcoded — this is the expected compilation output when model: is explicitly set in the frontmatter; the dynamic vars fallback only applies when no model is specified.

No logic errors, security issues, or broken behavior found.

🔎 Code quality review by PR Code Quality Reviewer · 74.7 AIC · ⌖ 6.94 AIC · ⊞ 5.2K

[github-actions]

body_hash was also stale (not just frontmatter_hash) — and there is currently no test that would have caught it.

💡 Details

The lock file was introduced in fbee0bc compiled from an older markdown version (pre-model: claude-sonnet-4-6). The body_hash has been stale since day one — silently, because TestHashConsistencyAcrossLockFiles only validates frontmatter_hash, never body_hash, even though LockSchemaV4 added body_hash explicitly for "full stale-check coverage".

A future change that modifies the workflow body without updating the lock file would go undetected.

This PR correctly refreshes both hashes so it is not a blocker here — but closing the test gap (adding body_hash validation to TestHashConsistencyAcrossLockFiles) would make the guarantee complete.

[github-actions]

Hey @Copilot 👋 — great catch on the stale frontmatter_hash in design-decision-gate.lock.yml! Recompiling the lock file after model: claude-sonnet-4-6 was added to the workflow's frontmatter is exactly the right fix to unblock TestHashConsistencyAcrossLockFiles.

One minor note from the checklist:

• No test file changes — the diff only touches the auto-generated lock file, which is fully expected for this type of fix. TestHashConsistencyAcrossLockFiles already validates lock-file integrity, so no new tests are required here. This flag is mechanical rather than a real gap.

The PR is focused, minimal (4 lines), and the description clearly explains the failing test, its root cause, and the fix. Looks ready for merge.

If you want to confirm the fix locally before merging, run:

  go test ./... -run TestHashConsistencyAcrossLockFiles

All assertions should pass with the updated frontmatter_hash and body_hash values.

Generated by ✅ Contribution Check · 244.9 AIC · ⌖ 18.7 AIC · ⊞ 6K · ◷