Evidence requirements
This page defines evidence requirements for connected agents implementing the Day Shift lifecycle. Behavioral compliance depends on the connected agent or integration. The core CLI exposes and validates repository policy, but it cannot force an unsupported agent to comply.
Required context
Section titled “Required context”Resolve and preserve these fields before editing:
taskDefinitionPath,implementationSummaryPath, and the current task revisionagent_modeandevidence_profileas independent dimensionsreadinessReviewId,attemptId, and, for Runtime or Hybrid work,baselineId- declared target paths, acceptance criterion IDs, validation identities, and recovery boundary
Never infer a higher autonomy level, a different evidence profile, or broader authority from the other field.
Profile requirements
Section titled “Profile requirements”For runtime, require a post-readiness, pre-write baseline, at least one fresh runtime-eligible declared target, current-attempt executable validation, exact inherited runtime criterion IDs, recorded adoptions, and ineligiblePaths: [].
For contract, require current contract validation and authored acceptance evidence. Do not fabricate runtime attribution or claim executable behavior.
For hybrid, require both the contract evidence and every Runtime requirement.
Attempt and validation requirements
Section titled “Attempt and validation requirements”Open one readiness-bound attempt before implementation. Preserve superseded or closed attempts as history; do not overwrite their identities. Record validations with unique validationId values. Command-owned execution must preview exact argv, then execute once on apply. Manual, CI, and imported evidence must retain their source, scope, status, and bounded references. A waiver must name the validation it affects and cannot convert missing proof into runtime success.
Review and write boundary
Section titled “Review and write boundary”Treat task readiness-review, task review, implementation-summary review, reconciliation review, validation smoke, and validation links-check as read-only. Their findings and recovery guidance are not writes.
Use only the dedicated explicit transition for authorization: task readiness-authorize, task implementation-complete, task disposition, task close, reconciliation accept, metadata sync-status-from-review, or a revision-bound apply supported by the selected command. Never translate a recommendation into an adjacent mutation.
Canonical evidence and receipts
Section titled “Canonical evidence and receipts”Keep implementation-summary.md as the canonical technical evidence artifact and create or refresh it with implementation-summary build. Record exact changed declared targets, acceptance results, validations, deviations, waivers, blockers, and follow-up work. Put necessary non-target dependency changes in Deviations with exact path-to-target mapping rather than claiming them as fresh runtime targets.
Consume a fresh zero-blocker review receipt for disposition, closeout, or reconciliation acceptance. A receipt proves the matching mutation applied; it is not independent authority for another mutation.
Stop and escalate
Section titled “Stop and escalate”Stop when readiness or evidence is missing, a revision or validation is stale, validation fails or remains incomplete, a path would exceed scope, an approval is required, a destructive action is proposed, external-system authority is absent, or disposition and closeout ownership is unclear. Report the exact record, failed precondition, evidence already gathered, residual risk, and safe next read-only command.