Claude/settings development section - #2141
Conversation
… Contact prototype Settings gains a Development section at the bottom of the rail, holding the in-progress surfaces while they are being built. Its first entry opens the Caring Contact linked prototype. - Gated on the same two conditions as `mockupsEnabled()` in src/lib/env.ts, read from bundler-inlined values rather than by importing that module: no client component imports the server env contract, and tests/client-secret-surface.test.ts holds that boundary. In a production deploy that has not opted in, the section does not render — which is exactly when /mockups/* would 404. - The desktop rail is filtered from the same predicate, so it cannot advertise a section the body does not render. The scroll-spy already reads section ids from the DOM, so a hidden section cannot desync it. - Navigation uses <Link> per docs/wiring-conventions.md and closes the sheet behind it. The card states plainly that the prototype is synthetic-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Settings → Development now opens a real page rather than linking straight into a prototype, so there is one place that lists what is being built. - `/mockups/development` indexes the in-progress surfaces. Each carries a summary, a primary button into it, and direct links to its key routes — for Caring Contact: Today, Patients, Schedule, Templates and System states. - It lives under `/mockups` on purpose: the namespace layout already applies `mockupsEnabled()`, so the page inherits the production gate and 404s in a production deploy exactly like the surfaces it links to, rather than needing a second gate of its own. - The page states plainly that everything on these surfaces is synthetic and that none of it is validated clinical decision support. - The Settings card now points at the page and is renamed accordingly. Verified on the running app: `/mockups/development` and `/mockups/caring-contacts` both return 200, the page renders its five outbound prototype links, and the settings entry resolves to `/mockups/development`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:30 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the 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 reviews. How do review 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 refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Comment |
BigSimmo
commented
Aug 18, 2026
Closing as fully superseded. Verified against current Generated by Claude Code |
Pull request was closed
Summary
Verification
npm run verify:pr-localDuring development, use
npm run verify:cheapas the faster iteration gate before the final PR-local preflight.npm run verify:uiwhen UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changednpm run verify:releasebefore release or handoff confidence claimsFor retrieval, ranking, selection, chunking, source/citation rendering, or answer-contract changes,
verify:pr-localrunseval:rag:offlineautomatically. Run the offline command directly during iteration before spending a live eval.npm run eval:retrieval:quality(must stay 36/36) when retrieval, ranking, selection, chunking, or scoring behavior changed — CI cannot run it (needs live keys), so run it locally and paste the summary. A metadata/governance-weighting change once buried correct docs (recall 1.0→0.76) and only this eval caught it.npm run eval:rag -- --limit 15+npm run eval:quality -- --rag-onlywhen answer generation, the synthesis prompt, or answer post-processing changed (grounded-supported must not drop; citation-failure 0)npm run check:production-readinesswhen clinical workflow, privacy, environment, Supabase, source governance, or deployment behavior changednpm run check:deployment-readinesswhen deployment startup, hosting, or rollout behavior changedRisk and rollout
Complete this section for clinical, data, API, auth/privacy, workflow, dependency, build, or deployment changes.
Clinical Governance Preflight
Complete this section when the change touches ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output.
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes