docs: add RFC-0007 Figma Make Pipeline Integration

[deefactorial]

Summary

• RFC-0006: Design System Governance — governance framework for design systems
• RFC-0007: Figma-Make Pipeline Integration — automated Figma-to-code pipeline
• RFC-0008: PPA Triad Integration — combined PPA scoring across the triad

Test plan

• Docs-only change, no code impact

🤖 Generated with Claude Code

[github-actions]

AI-SDLC: Automated PR Review

One or more review agents found issues.

Testing Review: CHANGES REQUESTED

Review agent response was not valid JSON: ```json
{
"approved": true,
"findings": [],
"summary": "Three normative specification RFCs adding 8,859 lines. All are documentation/specification changes with no executable code. No testing con

Code Quality Review: CHANGES REQUESTED

Review agent response was not valid JSON: I'll analyze this pull request for the three new specification RFCs (RFC-0006, RFC-0007, RFC-0008). Let me examine them systematically.

{
  "approved": true,
  "findings": [],
  "summary": "A

### Security Review: APPROVED

No security vulnerabilities identified. This PR adds three normative specification documents (RFC-0006, RFC-0007, RFC-0008) defining design system governance, Figma Make integration, and PPA triad integration. These are documentation files with no executable code, authentication mechanisms, or data processing that could introduce security risks.

### General Findings

- 🔴 **[testing/critical]**: Failed to parse review verdict — treating as not approved
- 🔴 **[critic/critical]**: Failed to parse review verdict — treating as not approved

---
*Reviewed by [AI-SDLC Review Agents](https://github.com/ai-sdlc-framework/ai-sdlc) — 0 inline comments posted*

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

AI-SDLC: review attestation not accepted

CI didn't find a valid review attestation for this PR (schemaVersion 'v1' not in allowlist [v3]), so it ran its
own review instead. Heads-up: that's the slower + more token-heavy path.

How to skip CI review on your next PR

1. One-time setup (per machine): /ai-sdlc init-signing-key, then open
   the printed onboarding PR adding your pubkey to
   .ai-sdlc/trusted-reviewers.yaml. Once that PR merges, /ai-sdlc execute
   will produce attestations CI accepts.
2. Per task: run /ai-sdlc execute <task-id> instead of pushing manually.
   It runs the three reviewer subagents locally, signs a DSSE envelope at
   .ai-sdlc/attestations/<head-sha>.dsse.json, and commits it alongside
   your work. CI then verifies the signature and skips its review.

Why CI still ran a review this time

The most common causes:

• No attestation file present (you pushed without /ai-sdlc execute).
• Diff changed after the attestation was signed (force-push, manual amend).
• .ai-sdlc/review-policy.md or a reviewer agent file changed since you signed.
• The signing key isn't in .ai-sdlc/trusted-reviewers.yaml yet.
  See CLAUDE.md → "Review attestations" for the full bootstrap flow.
  Head SHA: 46ac3b23f7df1a77c89e773c09e49d8b4a7c8aec

[github-actions]

AI-SDLC: Automated PR Review

All three review agents approved this PR.

Testing Review: APPROVED

This is a comprehensive, well-structured RFC specification document introducing Figma Make pipeline integration. All five validation stages are clearly defined with deterministic-first principles. The document correctly defers to CI for deterministic checks and focuses on design-time governance concerns that CI cannot catch. No critical or major testing issues found - the suggestions focus on implementation guidance and documentation consistency.

Code Quality Review: APPROVED

This is a comprehensive, well-structured RFC introducing Figma Make pipeline integration. The five-stage validation architecture is sound, the adapter interface is clear, and integration points with RFC-0006/0008 are well-defined. Three minor suggestions focus on internal spec consistency (PPA v1.2 dependency timing, OQ-4 resolution path, and open question status). No logic errors or security issues identified.

Security Review: APPROVED

This RFC is a comprehensive specification document with no executable code. All security considerations are architectural and appropriately addressed in §16. No injection vulnerabilities, credential exposure, or unsafe patterns found in the YAML/TypeScript schema examples.

General Findings

• 💡 [testing/suggestion] Consider adding a test specification section defining how implementations should validate conformance to the five-stage validation pipeline, especially for the deterministic Stages 1-4. This would help ensure adapter implementations are testable and behavior is verifiable across teams. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:1)
• 💡 [testing/suggestion] The handoff to PPA v1.2 for quantifying the IntentTraceabilityWarning penalty is clear, but consider documenting the expected timeline or blocking dependency. If PPA v1.2 is not yet published, implementations may need interim guidance on how to handle warnings during the transition period. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:584)
• 💡 [testing/suggestion] OQ-4 correctly identifies the expiry semantics gap. Since this is marked as 'Signed Off' status, consider moving OQ-4 from open questions to a resolved amendment in the revision history, or explicitly state that it will be addressed in a v1.1 revision. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:1536)
• 🟡 [testing/minor] Author field on line 23 contains placeholder text '[Author Name]' while the Sign-Off table and Revision History correctly list Dominique Legault, Morgan Hirtle, and Alexander Kline. Update line 23 to match the actual authors for consistency. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:23)
• 💡 [critic/suggestion] Section 5.4 and 14.3 reference PPA v1.2 for missing-DID penalty quantification, but RFC does not specify timeline or fallback if PPA v1.2 is delayed. Consider adding a note about interim behavior or making the contract explicit. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:414)
• 💡 [critic/suggestion] OQ-4 correctly identifies that 'pause the pipeline' is ambiguous for already-emitted PRs. The suggested resolution (expiry affects only future runs) should be codified in §9.3 rather than left as an open question in a Final RFC. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:1489)
• 🟡 [critic/minor] RFC lifecycle is 'Signed Off' with status 'Final', but §18 contains 5 open questions. Standard practice for Final RFCs typically resolves all OQs before sign-off. Consider whether these are deferrable implementation notes vs. blocking design questions. (spec/rfcs/RFC-0007-figma-make-pipeline-integration-v1-final.md:24)

---

Reviewed by AI-SDLC Review Agents — 7 inline comments posted