[WRONG BRANCH] chore: sync plugin lane with reviewed plan

[OnlineChef]

Temporary branch-sync PR: merge the reviewed PR #39 plan correction into feat/plugin-contract. The branches touch disjoint files; this prevents PR #40 from reverting the parent review fix.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

Greptile Summary

This change documents the planned plugin isolation, protected metrics, rate limiting, diagnostics, benchmarks, and validation work. The rate-limit persistence design remains incomplete: a running server can overwrite an operator’s on-disk rate-limit change during an unrelated configuration save.

Confidence Score: 4/5

T-Rex Logs

What T-Rex did

• Ran the ratelimit-persistence-validation.ts validation script to model the future rate-limit subtree and exercise the guarded saver.
• Observed the pre-save value 99 and the post-save value 10 after an unrelated save, confirming the persistence behavior.
• Confirmed the focused rate-limit persistence tests (Claude-only preservation tests) pass.
• Reviewed the two finding-proof proofs for the posted P1 finding and linked to the supporting artifacts from proof 0.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Rate-limit persistence plan relies on a reconciliation flow that does not preserve rate-limit edits

   • Bug
     • Lines 184-187 state that optional rate-limit settings will use the existing config load/save reconciliation flow. The current live-save wrapper only checks, adopts, and rebases the claudeCode subtree. Therefore, after the planned rate-limit settings are persisted, an operator editing them on disk while the server runs can lose the edit when any unrelated live mutation saves the whole stale config object.
   • Cause
     • saveConfigPreservingClaudeCode reads and reconciles only onDisk.claudeCode against claudeCodeBaseline; its own scope comment says that only claudeCode is reconciled and other hand edits are clobbered. The plan does not specify a rate-limit baseline/reconciliation policy or otherwise prohibit runtime disk edits.
   • Fix
     • Amend the implementation plan to require rate-limit settings to participate in the live-save preservation mechanism (preferably a generalized subtree/field-aware three-way reconciliation with explicit conflict policy), arm its baseline at server startup, and add regression coverage for an on-disk rate-limit edit followed by an unrelated runtime save. Alternatively, explicitly state that runtime edits are unsupported and provide an atomic management/config-reload path, but that would be inconsistent with claiming the existing reconciliation flow handles persistence.

   _{Ran code and verified through T-Rex}

Prompt To Fix All With AI

### Issue 1
structure/plugin-metrics-ratelimit-benchmarks.md:184-187
**Rate-limit settings bypass reconciliation**

The plan routes persisted rate-limit settings through the existing config save flow, but that flow reconciles only the `claudeCode` subtree. If an operator edits a persisted rate-limit value while the server is running, an unrelated runtime save writes the stale in-memory rate-limit value back to disk and silently discards the operator’s edit. Require rate-limit settings to participate in the live-save baseline/reconciliation policy, with an explicit conflict policy, and add regression coverage for an on-disk rate-limit edit followed by an unrelated save.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "docs(structure): route rate-limit config..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

Context used:

• Context used - Focking gretig zijn en niet stoppen tot perfectie.... (source)

[qodo-code-review]

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (2)

• ^dev$
• ^preview$

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: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 57eb2e1b-a0d3-487e-850e-8eae3a147551

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

---

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

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

[github-actions]

⚠️ Wrong target branch

This pull request currently targets feat/plugin-contract, but pull requests must target one of dev or dev2-go.

Its title has been prefixed with [WRONG BRANCH].

OnlineChef Please retarget this PR to dev. Most contributions go to dev first; use dev2-go only for scoped Go native-port work. main receives only release promotions. See our Contributing guide for details. Thanks! 🙏

This pull request is being kept as a draft automatically. Once the target branch is corrected, it will be marked ready for review again.

[greptile-apps]

Rate-limit settings bypass reconciliation

The plan routes persisted rate-limit settings through the existing config save flow, but that flow reconciles only the claudeCode subtree. If an operator edits a persisted rate-limit value while the server is running, an unrelated runtime save writes the stale in-memory rate-limit value back to disk and silently discards the operator’s edit. Require rate-limit settings to participate in the live-save baseline/reconciliation policy, with an explicit conflict policy, and add regression coverage for an on-disk rate-limit edit followed by an unrelated save.

Context Used: Focking gretig zijn en niet stoppen tot perfectie.... (source)

Artifacts

Focused rate-limit persistence validation source

• Bun validation source models a persisted rate-limit edit and calls the actual live guarded save path, proving the exact behavior under review.

Persisted rate-limit setting before unrelated save

• The executed before run shows the operator's persisted management rate limit is 99 requests per minute, establishing the edited state.

Persisted rate-limit setting after unrelated save

• The executed after run shows an unrelated save persisted while the rate limit reverted from 99 to stale value 10, proving the edit is overwritten.

Existing narrow config preservation tests

• The focused Bun test run completed with 16 passing tests and zero failures, confirming the existing Claude-only reconciliation guard remains operational.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: structure/plugin-metrics-ratelimit-benchmarks.md
Line: 184-187

Comment:
**Rate-limit settings bypass reconciliation**

The plan routes persisted rate-limit settings through the existing config save flow, but that flow reconciles only the `claudeCode` subtree. If an operator edits a persisted rate-limit value while the server is running, an unrelated runtime save writes the stale in-memory rate-limit value back to disk and silently discards the operator’s edit. Require rate-limit settings to participate in the live-save baseline/reconciliation policy, with an explicit conflict policy, and add regression coverage for an on-disk rate-limit edit followed by an unrelated save.

**Context Used:** Focking gretig zijn en niet stoppen tot perfectie.... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.