docs(plans): C.9 framework plugin layer — plan PR (skeleton)

[SutuSebastian]

Summary

Opens the C.9 framework plugin layer plan PR per the parallel-plan-PR shape locked in by the just-merged research note (PR #58 — docs/research/non-goals-reassessment-2026-05.md § 5).

Why now (T+0): the research note's § 5 ship sequence parks (b) C.9 impl at T+2w → +5w in the shipping cadence. The plan PR opens at T+0 in parallel with (a) FTS5 + Mermaid shipping so impl is unblocked when its slot arrives — avoids the deferral trap where XL items become "next quarter" while every new recipe layered on the noisy dependencies substrate inherits untested-and-dead's false-positive class.

Motivator: closed-dead-subgraph case — N-file packs where every file imports a sibling (non-zero dependencies fan-in for all) but none is reachable from a real entry point. Today's untested-and-dead recipe false-positives Next.js app/**/page.tsx for the same reason — framework entry points aren't recognized as live without per-framework awareness.

What's in the skeleton

• 5 pre-locked decisions (L.1–L.5) carried from the research note with anchor-deep cross-references — entry-point hints only (no edge injection), static config only, moat-A clean (no verdict-shaped verb), moat-B aligned (substrate growth), no edge injection in v1.
• 9 open decisions (Q1–Q9) — plugin contract shape, discovery, schema delta, reachability algorithm, bundled starters, conflict resolution, recipe composition, community API, backwards-compat. Each gets a Resolution subsection as it crystallises (mirrors the research-note § 6 pattern).
• High-level architecture — plugin loader + indexer hook + reachability sweep. Recipes consume the substrate.
• 5 implementation slices (tracer-bullets) — schema delta → reachability recipe → contract+discovery → bundled starters → agent rule lockstep update.
• Test approach — unit + golden queries + integration fixture under fixtures/golden/c9-fixture/.
• 6-row risks/non-goals table — including the abandonment escape hatch (close as Status: Rejected per Rule 8 if needed).

Doc-governance compliance

• Lives in docs/plans/c9-plugin-layer.md per Rule 3 — feature plans go in plans/, no -plan suffix (folder provides context).
• docs/README.md File Ownership row updated in the same PR per Rule 4 — plans/ "Empty until the first plan lands" no longer accurate.
• Cross-references use relative paths with section-deep anchors per Rule 5.
• No inventory counts in narrative per Rule 6.

Test plan

• bun run format:check passes
• All anchor cross-refs to docs/research/non-goals-reassessment-2026-05.md resolve to existing section anchors
• CodeRabbit review on the skeleton structure (rate-limited; will trigger)
• Plan iteration via subsequent commits as Q1–Q9 crystallise

Iteration cadence

Per the parallel-plan-PR shape: each open decision (Q1–Q9) gets resolved via a separate commit on this branch as it crystallises, with a "Resolution (YYYY-MM-DD)" subsection added inline (mirrors the research-note § 6 resolved-vs-open pattern). The plan stays in iterative state until impl-ready; merges with the impl PR per the cadence at T+5w.

Out of scope (separate PRs)

1. Impl itself — gated on this plan converging.
2. docs/research/fallow.md cleanup under the new positioning — separate PR.
3. docs/roadmap.md § Non-goals lockstep update — separate PR per Rule 10.
4. Tier-2 rule for plan-PR inspiration discipline — separate PR.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b53db60

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Warning

Rate limit exceeded

@SutuSebastian has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 42 minutes and 27 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1aa301d3-7830-48cb-a552-362e0df3be9d

📥 Commits

Reviewing files that changed from the base of the PR and between 54e3a2c and b53db60.

📒 Files selected for processing (2)

• docs/README.md
• docs/plans/c9-plugin-layer.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch plan/c9-plugin-layer

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 42 minutes and 27 seconds.}

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