Evidence note: This article draws on project maintainers’ official documentation and PlayAgit’s own pipeline records for August 28–October 8, 2026, as recorded on October 8. Documentation establishes what maintainers describe; operational effectiveness remains unverified here. Pipeline figures are PlayAgit’s measurements, not an independent audit. Calculations below are identified as derived analysis.
The practical finding is a reconciliation problem. PlayAgit’s own records covering 167 runs from August 28–October 8, 2026 report 1,192 publications, including 348 new posts and 336 updates. Subtracting those categories from the reported total leaves 508 unexplained by the supplied breakdown. That is a derived accounting difference, not evidence that publications disappeared or bypassed review.
For developers evaluating agentic delivery, the distinction matters: a documented gate, a recorded decision, and a reconciled delivery total answer different questions.
What delivery frameworks document
According to its official process documentation, icebox-cli describes six steps, five gates, and a production feedback loop. Its sequence covers intake, specification preparation, implementation and testing, workflow controls, completion-evidence review, and merge and release. Production feedback returns to intake. icebox-cli’s process framework
The documentation places decisions between activities: readiness to begin, agreement on the specification, acceptance of test evidence, operational safeguards, and completion criteria. This gives developers a concrete design to inspect. icebox-cli’s gate descriptions
The URL-shortener project likewise describes its orchestration engine as incorporating a dependency graph, gates, governance, and observability. The project’s official description
These examples suggest a governance pattern in the selected documentation. They do not independently establish how consistently agentic software-development frameworks enforce such mechanisms in practice; that broader question remains open.
What supports a gate decision
The icebox-cli framework identifies pull requests, issue comments, and gate sign-offs as evidence supporting its gates. icebox-cli’s evidence requirements
For a development team adopting this approach, the useful decision criterion is traceability: can a reviewer connect the approval to the exact change, the relevant test results, and the reason it was allowed to proceed?
A sign-off should therefore identify the evidence it accepts. A pull request can locate the change; a review comment can explain a concern; an approval can record its resolution. Merely counting these artifacts would leave their relationship to the delivered result unanswered.
How review and continuity are organized
The projects describe different parts of the delivery problem:
- AgentCheck describes five local reviewers covering logic, security, style, guidelines, and product. Its documentation directs them to analyze staged changes and produce review reports. AgentCheck’s official documentation
- cc-pipeline describes orchestration through specification, research, planning, building, review, fixes, reflection, and commits. Its official page also marks the project deprecated as of May 2026, which matters when considering adoption. cc-pipeline’s official documentation
- VibrationPlan describes an adaptation of the software-development lifecycle for stateless AI agents, using specialized roles, explicit handoffs, and living documentation. VibrationPlan’s official description
- Distillery describes persistent, shared team context for AI coding sessions through an MCP server and team knowledge tools. Distillery’s official documentation
These descriptions offer separate evaluation questions: who reviews, what happens next, what a handoff preserves, and how later sessions recover context. PlayAgit’s related overview of review roles, delivery gates, and shared context provides additional reading on those distinctions.
PlayAgit’s August 28–October 8 records: discovery and scoring
PlayAgit’s own pipeline records for 167 runs from August 28–October 8, 2026, as of October 8, report 32,027 discovered topic candidates across four categories and 223 distinct source hosts.
PlayAgit’s own records for the same 167 runs and August 28–October 8, 2026 reporting period, as of October 8, separately report 37,866 scored topics.
The supplied aggregates contain no mapping between discovered candidates and scored topics. They therefore cannot support a discovery-to-scoring conversion rate. The reason the scoring count exceeds the discovery count remains open.
Before combining these stages into a funnel, an analyst would need the counting definitions and records connecting each scored topic to its discovery history.
Before production: held, rejected, and advanced
In PlayAgit’s own 167 pipeline runs from August 28–October 8, 2026, as of October 8, the 37,866 scored topics received these recorded dispositions: 14,747 held before production, 16,394 rejected, and 6,725 advanced to production.
A derived arithmetic check of those supplied figures reconciles:
14,747 + 16,394 + 6,725 = 37,866.
That establishes that the reported disposition counts sum to the reported scoring total. It does not establish whether the decisions were appropriate, whether each topic was unique, or what eventually happened to held topics.
For developers, this is a useful boundary: arithmetic reconciliation is a check on a summary, not an evaluation of the gate’s judgment.
Evidence and draft decisions
Across PlayAgit’s own 167 runs from August 28–October 8, 2026, as of October 8, its records report 5,102 research dossiers containing 29,715 claims, with 1,752 recorded as independently cross-checked and 6,651 recorded as primary-attested.
Those labels describe different support. Primary attestation can establish that a subject made an announcement or documented a feature. Independent cross-checking concerns corroboration beyond that subject’s account. The supplied aggregate does not show which claims reached published articles, so it cannot establish the evidence composition of the final publication set.
PlayAgit’s own quality-gate records for 167 runs from August 28–October 8, 2026, as of October 8, report 1,374 reviewed drafts: 1,140 marked published, 140 returned for revision, and 94 rejected.
A derived check of those supplied outcomes also reconciles:
1,140 + 140 + 94 = 1,374.
The outcomes account for the reported reviewed-draft total. They do not provide a record-by-record connection to the separate publication aggregate.
Where the publication breakdown stops reconciling
PlayAgit’s own publication records for 167 runs from August 28–October 8, 2026, as of October 8, report 1,192 published posts, with 348 new posts and 336 updates.
The derived reconciliation is:
| Calculation from the supplied publication figures | Result |
|---|---|
| New posts plus updates: 348 + 336 | 684 |
| Reported publications minus those categories: 1,192 − 684 | 508 |
This calculation assumes the categories are intended to partition the same publication total. The supplied summary does not establish that they are exhaustive, mutually exclusive, or counted on an identical basis.
Consequently, 508 is the unexplained remainder of the supplied breakdown, not a verified category of publication. Its cause remains open. Assigning it to another workflow, a counting error, or any particular publishing behavior would exceed the evidence.
What developers can conclude
Keep the acceptance criteria separate:
| Evidence available | Conclusion it supports | Evidence still needed |
|---|---|---|
| Maintainer documentation | The project describes a governance mechanism | Execution records showing enforcement |
| Recorded gate outcomes | The system recorded decisions | Decision evidence linked to specific artifacts |
| Reconciled aggregate counts | The stated categories sum correctly | Record-level checks of identity and counting scope |
| Publication summary | The operator reports delivery volume | Publication records linked to decisions and categories |
A practical review should ask whether each stage preserves identity, whether state changes remain inspectable, and whether a delivery total can be regenerated from underlying records.
This distinction also limits performance claims. The supplied data does not establish that these frameworks improve delivery speed or quality, or that PlayAgit’s gate decisions caused better published results.
Which publication records explain the remaining 508?
The concrete follow-up is to identify the publication records behind the derived remainder of 508, calculated from PlayAgit’s own 167-run publication summary for August 28–October 8, 2026, as of October 8.
A proposed reconciliation should:
- Define whether the headline total counts unique posts, publication events, or another unit.
- Retrieve the records contributing to that total, with timestamps and stable post identifiers.
- Link each record to its publication category and originating gate decision where available.
- Recalculate the total and category breakdown under the same reporting window and counting rules.
- Report unmatched records explicitly, leaving their classification open until supported.
This is proposed follow-up work. The supplied evidence does not include a completed reconciliation.
Implementation Note
For Vision, the immediate application is to preserve the distinction between recorded decisions and reported delivery.
PlayAgit’s own records for 167 runs from August 28–October 8, 2026, as of October 8, show 1,374 reviewed drafts, with 1,140 marked published, 140 returned for revision, and 94 rejected. These figures support a view of recorded quality-gate outcomes.
PlayAgit’s own records for 167 runs from August 28–October 8, 2026, as of October 8, separately report 1,192 publications, 348 new posts, and 336 updates. These figures support a publication summary whose relationship to the gate outcomes remains unresolved in the supplied evidence.
Vision should present those summaries with their counting definitions and require a traceable connection before presenting them as an end-to-end delivery account. The available records support that development requirement; they do not establish that Vision already implements it.