When to start a company pilot.
A checklist of outcomes, not just available settings.
Current state
Technical evaluation. A bounded real MR3 is preserved. Full acceptance of the current build is incomplete. The website design and green component tests do not change this status.
Launch gates
| Area | Required outcome |
|---|---|
| Installation | Clean Linux amd64 host, current package, all stages, useful operation and version correspondence. |
| SSO / tenants | Two tenants, real roles, cross-tenant denial, logout and restart. |
| ContextForge | SSO, enrollment, consent, useful protected read, revocation and restart. initialize/list alone is insufficient. |
| GitLab / model / CI | A defective MR, assignment/mention, finding, fix, new SHA, re-review, current CI and authorized approve without duplicates. |
| Recovery | Ambiguous API outcomes, retries and restarts do not duplicate publication or CI. Backup restoration is tested. |
| Load | Five real overlapping reviews, queue, memory, cost, provider limits and p95 against agreed thresholds. |
Run a bounded pilot
- Start with one repository and an accountable technical lead. Agree on criteria and a time window first.
- Use historical MRs with known defects. Track useful findings, false positives and misses separately.
- Evaluate drafts first. Enable publication and approve separately after permission and freshness checks.
- Record cost, load and the team’s decision. Expand scope only after acceptance.