Purpose
This issue is the canonical product-evaluation ledger for the 30-day pilot window. It records required-check continuity, false positives, and repair time across two public repositories.
Current candidate segment
- Candidate:
v1.0.0rc11
- Commit:
f6ce8bd1c45810156aa627d4312c8bc7d080d553
- Common window start:
2026-07-13T15:57:37Z
- Earliest 30-day close:
2026-08-12T15:57:37Z
- Required check context:
clean-docs / clean-docs
- Scheduled check: daily at
05:17 UTC, plus pull requests and pushes to main
The clock starts at the later default-branch receipt after both pilots adopted the fixed candidate and branch protection was reverified.
Pilot baseline
Ultra CSM has 32 exact, reasoned exceptions for near-duplicate reference material and runtime prompt or evaluation source assets. Agent Governance Lab retains one exact exception for a protected operating-rules file. Both repositories have zero active findings and zero stale baseline entries.
Measurement rules
- A false positive is a clean-docs gate failure where source-bound documentation is current and the repository violates no documented clean-docs rule.
- A true positive is a gate failure repaired by changing a bound document, its source, its explicit baseline, or its reasoned ignore record.
- Repair time runs from the first failing required-check completion to the first passing run on the repaired commit.
- Infrastructure failures outside clean-docs are recorded separately and do not count as documentation false positives.
- Candidate or pilot-configuration changes start a new documented segment; prior observations remain part of the evaluation dataset.
Current metrics
| Metric |
ultra-csm |
agent-governance-lab |
| Observed false positives |
0 |
0 |
| Observed true positives |
0 |
0 |
| Repair events |
0 |
0 |
| Unexplained required-check failures |
0 |
0 |
Pre-window dogfood findings
These defects were found and repaired before the observation clock. They do not count toward the window metrics.
- Mature repositories needed an exact, explicit baseline for existing documentation debt.
- Valid directory links were rejected by one projection path.
- Bootstrap initially moved live configuration documents instead of preserving the corpus.
- Repository summaries were too large for a README.
- Repository-overview evidence was hashed before canonical ordering, which made a correct bootstrap PR fail nondeterministically.
- The reusable Action assumed the host repository had a root Python dependency file.
- Action artifacts did not bind the installed candidate, source commit, run identity, or raw evidence digests.
- The generated product overview duplicated the release label outside its source-bound evidence.
- The writing standard described a specific voice, but the runtime prompt and audit path enforced only a narrow prose subset. The project README exposed the gap.
- The prerelease build imported an optional stable-release dependency at module load, which broke the release-artifact job in a minimal build environment.
- The stable reader-trial rubric omitted the README purpose-identification task required by the Version 1.0 E2E.
- Python inventory evidence hashed CPython's version-specific AST serialization, so Python 3.12 and 3.14 produced different repository-overview digests for identical source.
- Repository-wide catalog coverage was reported as direct protection, decorative lead blocks could become purpose contracts, canonical agent indexes omitted declared pages, and documented CLI examples were not parser-verified. RC10 separates direct binding from catalog coverage, skips decorative lead blocks, supports declared canonical index pages, and parses every published CLI example in tests.
- Mature-monorepo initialization needed bounded planning, nested package and MCP registration discovery, conservative document classification, and an explicit gap instead of a manufactured purpose contract. RC11 adds those constraints and a Reter-shaped regression fixture.
Evaluation completion
The evaluation window completes after 30 observed days if both repositories retain the required check, all scheduled and change-triggered runs are accounted for, and every false positive and repair event has a receipt. This window gathers operating data and does not block the stable release. Stable release readiness is evaluated separately through the four isolated model trials and the Version 1.0 product DoD.
Purpose
This issue is the canonical product-evaluation ledger for the 30-day pilot window. It records required-check continuity, false positives, and repair time across two public repositories.
Current candidate segment
v1.0.0rc11f6ce8bd1c45810156aa627d4312c8bc7d080d5532026-07-13T15:57:37Z2026-08-12T15:57:37Zclean-docs / clean-docs05:17 UTC, plus pull requests and pushes tomainThe clock starts at the later default-branch receipt after both pilots adopted the fixed candidate and branch protection was reverified.
Pilot baseline
ultra-csm6983e98ddfefa8f5c1cb66c929979f95cafa058fagent-governance-lab616d3d9712ce6b8e209517d15321d6417078c884Ultra CSM has 32 exact, reasoned exceptions for near-duplicate reference material and runtime prompt or evaluation source assets. Agent Governance Lab retains one exact exception for a protected operating-rules file. Both repositories have zero active findings and zero stale baseline entries.
Measurement rules
Current metrics
ultra-csmagent-governance-labPre-window dogfood findings
These defects were found and repaired before the observation clock. They do not count toward the window metrics.
Evaluation completion
The evaluation window completes after 30 observed days if both repositories retain the required check, all scheduled and change-triggered runs are accounted for, and every false positive and repair event has a receipt. This window gathers operating data and does not block the stable release. Stable release readiness is evaluated separately through the four isolated model trials and the Version 1.0 product DoD.