feat(sdd): add SDD infrastructure and runner as first managed component

[jeremyeder]

Summary

• Introduces Spec-Driven Development (SDD) infrastructure for gradually migrating components to agent-managed governance
• Adds SDD manifest (.specify/sdd-manifest.yaml) declaring managed components, their paths, constitutions, specs, and enforcement mode (warn/enforce)
• Adds CI preflight workflow (.github/workflows/sdd-preflight.yml) that comments on PRs touching managed paths — warns in warn mode, blocks in enforce mode
• Onboards the runner as the first SDD-managed component with its constitution and spec extracted from PR feat(runner): upgrade to UBI 10, add glab CLI, pin versions, add freshness workflow #1091 patterns
• Supports sdd-exempt label to bypass enforcement when needed

Files added

File	Purpose
.specify/sdd-manifest.yaml	Central manifest of managed components
.specify/constitutions/runner.md	Runner constitution (6 principles: version pinning, freshness, update procedure, layer discipline, schema sync, bridge modularity)
.specify/specs/runner.md	Runner component spec (boundary, current state, maintenance, change protocol)
.github/workflows/sdd-preflight.yml	CI enforcement workflow

How it works

1. PR is opened touching files in a managed component's paths
2. Preflight job parses the manifest with yq, converts glob patterns to regexes
3. Matches changed files against managed paths
4. Posts a PR comment with findings (warn = informational, enforce = check fails)
5. sdd-exempt label skips the check entirely (job-level if)

Test plan

• Open a test PR touching components/runners/ambient-runner/ and verify preflight comments
• Verify sdd-exempt label skips the check
• Verify PRs not touching managed paths get no comment
• Review runner constitution and spec for accuracy against current codebase

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6052f0bb-7a4f-45b9-ac6f-d70ebb7ce755

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/sdd-infrastructure

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[markturansky]

Balanced Take on SDD Infrastructure

The Vision: Constitutional governance for agent-maintained components is genuinely interesting. The separation of constitution (principles) / spec (current state) / manifest (enforcement) is clean architecture.

The Gap: You're building agent infrastructure before you have an agent. The CI doesn't validate constitutional compliance (R-I through R-VI) — it just checks "did you touch these paths?" That's documentation enforcement, not governance.

The Risk:

• The spec will drift from reality (no automated sync between specs/runner.md and actual Dockerfile versions)
• The bash glob→regex conversion is fragile (sed 's/\*\*/.*/g' doesn't handle brace expansion, character classes, etc.)
• Overhead (CI time, bot comments, sdd-exempt labels) without proven ROI

What's Actually Valuable Right Now:
The constitution and spec themselves are excellent documentation. They codify patterns that should be followed (version pinning, layer discipline, schema sync). That's useful even without an agent.

---

Recommendation

Split this PR into two pieces:

Ship Now: Documentation

.specify/
  constitutions/runner.md  ✅
  specs/runner.md          ✅
  
docs/CONTRIBUTING.md       (link to constitution)

These docs help human maintainers understand component governance. No CI overhead.

Ship Later: Enforcement Infrastructure

When you have a persistent agent session that actually maintains the runner:

• Add the manifest + CI preflight
• Validate constitutional compliance, not just paths (check version pins exist, layers are optimized, etc.)
• Use a proper glob library instead of bash regex conversion

---

Why Wait on CI?

1. You'll learn what enforcement needs to look like once you have a real agent making changes
2. The constitution might evolve based on agent behavior
3. No point enforcing a boundary when there's no designated agent to route changes to

Right now, the preflight job tells developers "use the component's agent workflow" — but that workflow doesn't exist yet. That's confusing, not helpful.

---

tl;dr: The thinking is solid, but you're building the parking garage before anyone owns a car. Keep the docs (they're great!), hold the CI until you have an agent that needs it.