Record command provenance at edit planning

[flyingrobots]

Summary

This PR closes #168 by recording command provenance as an immutable edit-planning artifact instead of reconstructing it later from mutable editor state.

What changed

• Added planned command provenance events keyed by text edit request id.
• Stored pendingCommandEvent and lastCommandEvent on opened text authority.
• Created planned Vim command events when production normal-mode edits are queued.
• Enriched stored command events with Echo receipt ids when edit settlement arrives.
• Updated Echo History and :why to prefer stored request-matched command evidence.
• Added regressions proving stale lastVimEdit, stale receipt posture, and drift before settlement do not corrupt command attribution.

Why

PR #167 made :why useful, but review found the fragile class underneath it: command facts could be reconstructed from whatever the editor or authority happened to remember later. This patch keeps command evidence attached to the edit request that produced it.

Validation

Passed locally:

• npm run build
• focused command provenance / Echo History / Vim repeat / witness specs: 38 pass
• npm run --silent quality
• npm run check
• git diff --check

Latest full check:

• 1034 tests
• 1025 pass
• 9 skipped
• quality regressions: none

Review focus

Please review especially:

• request-id matching between planned events and settled receipts;
• authority storage of pendingCommandEvent / lastCommandEvent;
• :why fallback behavior when no stored event exists;
• Echo History summary behavior for non-Vim edits.

[coderabbitai]

Warning

Review limit reached

@flyingrobots, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 34 minutes. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more credits in the billing tab to continue.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0af0cf8d-f570-48fb-b58d-a263819b9bd7

📥 Commits

Reviewing files that changed from the base of the PR and between 9c040d5 and f113329.

📒 Files selected for processing (6)

• spec/workspace-command-line.spec.mjs
• spec/workspace-echo-history-drawer.spec.mjs
• src/app/workspace/command-provenance.ts
• src/app/workspace/viewer-key.ts
• src/app/workspace/workspace-text-authority.ts
• src/app/workspace/workspace-text-runtime-state.ts

---

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.}