fix(cli): surface policy-group materials during attestation

[migmartri]

Summary

Fixes #3222.

Materials declared by a policy group attached to a contract were not surfaced during attestation for V2 contracts. The CLI enriched the contract's expected-materials list only on the V1 schema, but the crafter stores the V2 schema when it is present, so the enriched V1 was discarded and the policy-group materials never appeared in attestation status/add (nor were they validated as expected).

This change enriches the schema that the crafter actually stores — the V2 schema when present, V1 otherwise — so policy-group materials are merged into the expected-materials list alongside the contract's own materials.

It also clarifies the duplicate-material handling: when the same material is declared in both the contract and an attached policy group, the definitions are now merged silently when compatible, and a clearer warning is emitted only when the material types genuinely conflict.

Tested locally, below is an example of a material called sbom that comes from the policy group

hainloop attestation init --project policygrouptest --workflow test --replace
WRN User-attended mode detected. This is intended for local testing only. For CI/CD or automated workflows, please use an API token.
This command will run against the organization "miguel-test"
Please confirm to continue y/N
y
INF Attestation initialized! now you can check its status or add materials to it
┌───────────────────────────┬────────────────────────────────────────┐
│ Initialized At            │ 18 Jun 26 14:43 UTC                    │
├───────────────────────────┼────────────────────────────────────────┤
│ Attestation ID            │ 918bf69a-6365-480a-a798-f06fd9586e37   │
│ Organization              │ miguel-test                            │
│ Name                      │ test                                   │
│ Project                   │ policygrouptest                        │
│ Version                   │ v1.100.11+next (prerelease)            │
│ Contract                  │ contract-fix-policy-group (revision 1) │
│ Timestamp Authority       │ http://timestamp.digicert.com          │
│ Policy violation strategy │ ADVISORY                               │
│ Policies                  │ ------                                 │
│                           │ sbom-present: missing SBOM material    │
└───────────────────────────┴────────────────────────────────────────┘
┌────────────────────────────────┐
│ Materials                      │
├──────────┬─────────────────────┤
│ Name     │ sbom                │
│ Type     │ SBOM_CYCLONEDX_JSON │
│ Set      │ No                  │
│ Required │ Yes                 │
└──────────┴─────────────────────┘

in previous versions of the CLI the material was not present nor enforced

AI disclosure

This change was produced with the assistance of Claude Code. Affected commits carry an Assisted-by: Claude Code trailer.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri

[chainloop-platform]

AI Session Analysis

Avg score	Sessions	Failing policies	Attribution	Files	Lines	Total Duration
🟡 83%	1	✅ 0	100% AI / 0% Human	2	+169 / -40	58m36s

🟡 83% — 100% AI — ✅ All policies passing

Jun 18, 2026 13:24 UTC · 58m36s · $16.34 · 125.1k in / 151.9k out · claude-code 2.1.181 (claude-opus-4-8)

View session details ↗

Change Summary

• Researches the V1/V2 schema mismatch behind missing policy-group materials during attestation.
• Adds V2 regression coverage for missing materials and duplicate-material merging.
• Updates attestation_init to enrich the stored schema and then restores fail-fast ordering before control-plane init.

AI Session Overall Score

🟡 83% — Strong bugfix session, but planning, verification closure, and shipping autonomy lagged.

AI Session Analysis Breakdown

🟢 94% · scope-discipline

🟢 The recorded diff stayed inside attestation_init.go and its paired test file. · High Impact

🟢 93% · solution-quality

🟢 AI accepted cubic's fail-fast review and moved enrichment before control-plane side effects. · High Impact

🟢 90% · user-trust-signal

No notes.

🟡 78% · verification

🟢 AI reproduced the bug with a failing V2 regression before fixing it. · High Impact

🟠 Tests passed repeatedly, but the user never confirmed the final behavior after the last reruns. · Medium Severity

💡 When the user is present, ask for explicit confirmation after the final passing run.

🟡 72% · alignment

🟠 AI created, pushed, and opened PR #3223 without an explicit user request. · Medium Severity

💡 Before branching or opening a PR, ask whether the user wants you to ship.

🟡 72% · context-and-planning

🟠 The multi-step bugfix moved from research into edits without a visible shared plan. · Medium Severity

💡 For multi-step fixes, write three bullets before editing so the design stays explicit.

---

File Attribution

████████████████████ 100% AI / 0% Human

Status	Attribution	File	Lines
modified	ai	app/cli/pkg/action/attestation_init.go	+91 / -39
modified	ai	app/cli/pkg/action/attestation_init_test.go	+78 / -1

---

Policies (4)

Status	Policy	Material	Messages
✅ Passed	ai-config-ai-agents-allowed	ai-coding-session-db6ace	-
✅ Passed	ai-config-no-dangerous-commands	ai-coding-session-db6ace	-
✅ Passed	ai-config-no-secrets	ai-coding-session-db6ace	-
✅ Passed	ai-config-mcp-servers-allowed	ai-coding-session-db6ace	-

---

Powered by Chainloop and Chainloop Trace

[cubic-dev-ai]

1 issue found across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[migmartri]

Valid catch (identified by cubic). The previous ordering ran the V1 enrichment before the control-plane Init; consolidating the V1/V2 enrichment had moved it after Init, so a policy-group load failure could occur after a workflow run was created.

Fixed in a76ce6b's follow-up: enrichment now runs before client.Init again (both GetV1() and GetRawContract() are available right after the contract is fetched, so there's no dependency on the init result), restoring fail-fast before any side effect.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri