docs(tech-stack): clarify TUI snapshots don't gate CI

[vishnujayvel]

What

Launch-remediation audit item #12 (honesty form). The "Advanced Testing Tiers" table in docs/tech-stack.md listed pytest-textual-snapshot as preventing "Layout bugs" with no qualification — reading like an enforced visual-regression safety net.

In reality the dagger pipeline runs snapshots with --snapshot-update (container rendering differs from local macOS, so committed baselines won't match), which regenerates baselines rather than asserting them — a rendering regression can never fail CI. The dagger code comments already say this (dagger/main.go:222, :336) and docs/roadmap.md lists CI-gating as a future item; this makes the public tech-stack doc honest too.

Change

Doc-only: append a note to the table that snapshots are a local-only check, that the dagger pipeline regenerates rather than asserts, and that making visual regressions fail CI (committed container-rendered baselines) is a roadmap item.

Why doc-only (not "make CI assert")

The audit offered two paths; I took the honesty one deliberately. Committing container-rendered baselines and dropping --snapshot-update would make CI assert, but the repo has a documented history of snapshot flakiness across Python versions / container rendering — forcing assertions risks flaky CI failures. The honest, zero-risk fix is to stop the doc from implying enforcement that doesn't exist; actual gating stays a roadmap item.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

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

More reviews will be available in 37 minutes and 12 seconds. 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 refill rate.

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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 32bec768-58b8-404a-86cd-11d66a156186

📥 Commits

Reviewing files that changed from the base of the PR and between e5a35e4 and 550bc41.

📒 Files selected for processing (1)

• docs/tech-stack.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/snapshot-ci-honesty

---

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 and usage tips.}