docs: commit the production-readiness research write-ups (#364, #365, #366) - #603
Conversation
…366) The production-readiness, scalability, and security-audit assessments were completed in June but the findings only ever existed as GitHub issue comments. The reports they promised (docs/production-readiness.md, docs/scalability.md, docs/security-audit.md) were never written, so a reader of the repo had no way to find the sizing figures, the P0-P2 findings, or the measured capacity limits. Ports all three into docs/operations/ as reStructuredText, matching the existing Sphinx layout, plus a fourth page documenting the MinIO single-point-of-failure (#365 follow-up 4). Reconciles the two scopes that had drifted apart: the original #366 assessment targeted Kubernetes/Helm at 6.5-9 weeks, while the later leadership review scoped Stage 1 to a single server at ~15-20 days. Production-readiness now leads with that distinction and tracks the Stage 1 checklist against current issue state. Status is recorded as it actually stands: #376 and #378 done, #365 finding no critical index gaps, and backups (#379), credentials (#595) and UAT (#596) still open, with backups on the critical path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 35 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
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. Comment |
Problem
The production-readiness, scalability, and security-audit assessments were completed in June, but the findings only ever existed as GitHub issue comments. The reports they promised —
docs/production-readiness.md,docs/scalability.md,docs/security-audit.md— were never written.A reader of the repo had no way to find the sizing figures, the P0–P2 findings, or the measured capacity limits. It also made progress hard to assess: the work was real, just not where anyone would look for it.
What this does
Ports all three write-ups into
docs/operations/as reStructuredText, matching the existing Sphinx layout, plus a fourth page documenting the MinIO single-point-of-failure (#365 follow-up 4).production-readiness.rstsecurity-audit.rstscalability.rststorage-redundancy.rstReconciling two scopes
The assessments had drifted apart and this is the main editorial call in the PR:
Rather than silently pick one,
production-readiness.rstopens with a note stating both and declaring Stage 1 the current target, with the K8s findings retained as Stage 2. If that's the wrong framing it's one paragraph to change.Status is recorded as it actually stands
Not as the original assessment left it — #376 and #378 are done, #365 found no critical index gaps, and backups (#379), credentials (#595) and UAT (#596) remain open, with backups on the critical path.
Note on
storage-redundancy.rstWritten as a known limitation we are not fixing, not a hardening step. It includes an explicit note that redundancy is not backup, pointing at #379. Worth being blunt: that page reduces no risk, it records one.
Verification
Sphinx builds clean (
EXIT=0). All four pages render and every:doc:cross-reference resolves to a real link. Remaining build warnings are pre-existing in other files and untouched here.Refs #364, #365, #366
🤖 Generated with Claude Code