feat: add M10 release readiness evidence - #3
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 87f2c76f34
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!/^[0-9a-f]{40,64}$/i.test(normalized.commitSha)) { | ||
| throw releaseError('commitSha must be a hexadecimal Git object identifier', 'INVALID_RELEASE_COMMIT'); |
There was a problem hiding this comment.
An approved evidence object can retain the template's all-zero SHA, or use any arbitrary 40-character hexadecimal value, and still produce productionReady: true because this check validates only the string format. In the audit CLI's Git-checkout context, verify that the identifier resolves to the intended release commit; otherwise the resulting evidence cannot be tied to the code it claims to certify.
Useful? React with 👍 / 👎.
| function assertSafeReference(value, field) { | ||
| const reference = assertSafeText(value, field); | ||
| if (reference.includes('\\') || reference.split('/').includes('..')) { | ||
| throw releaseError(`${field} must be a repository-relative reference`, 'UNSAFE_RELEASE_REFERENCE'); |
There was a problem hiding this comment.
For evidence supplied by an operator, this condition accepts values such as /etc/passwd, /tmp/private-output, and https://example.test/evidence as repository-relative references because none contains a backslash or ... Those values can then be returned by createReleaseEvidence, contrary to the documented promise that published evidence contains no absolute local paths; explicitly reject leading slashes and URI schemes rather than relying on the narrow workstation-path regex.
Useful? React with 👍 / 👎.
| { "id": "governance.roles-delegation", "status": "verified", "evidence": ["src/admin/rbac.test.mjs", "src/admin/delegation.test.mjs", "doc/rbac-admin-mfa.md"] }, | ||
| { "id": "governance.master-log-access", "status": "verified", "evidence": ["src/admin/rbac.test.mjs", "doc/rbac-admin-mfa.md"] }, | ||
| { "id": "governance.api-mcp-readonly", "status": "verified", "evidence": ["doc/api-and-mcp.md", "src/admin/admin-tools.test.mjs"] }, | ||
| { "id": "governance.future-features", "status": "verified", "evidence": ["GULOGULO.md#30", "doc/release-readiness.md#future"] }, |
There was a problem hiding this comment.
In a clean checkout, this verified entry has no resolvable evidence: a repo-wide filename search shows that GULOGULO.md is absent, and doc/release-readiness.md has no #future heading (its generated anchor is #future-work-deliberately-outside-m10). Nevertheless the default audit counts this item as verified and reports the checklist complete, so either use real repository references here or make the audit resolve files and fragments before accepting them.
Useful? React with 👍 / 👎.
| function assertDate(value, field) { | ||
| const date = assertString(value, field, { max: 64 }); | ||
| if (Number.isNaN(Date.parse(date))) { | ||
| throw releaseError(`${field} must be an ISO-8601 date`, 'INVALID_RELEASE_DATE'); | ||
| } |
There was a problem hiding this comment.
When an evidence producer supplies malformed dates such as "1", "0", or "August 23, 2026", JavaScript's Date.parse accepts them even though the validator claims to require ISO-8601. This affects both generatedAt and approval timestamps, allowing ambiguously or falsely dated release evidence; validate the intended ISO representation explicitly and reject normalization-dependent inputs.
Useful? React with 👍 / 👎.
| const tests = Object.freeze((input.tests ?? []).map(normalizeTestEvidence)); | ||
| const decision = assertEnum(input.releaseDecision, 'releaseDecision', RELEASE_DECISIONS); | ||
| const normalized = { | ||
| evidenceVersion: assertString(input.evidenceVersion ?? RELEASE_EVIDENCE_VERSION, 'evidenceVersion', { max: 16 }), |
There was a problem hiding this comment.
For an input declaring evidenceVersion: "999" or another future schema, this code preserves the value while validating the object using the current 1.0 rules. Consumers can therefore be told that a newer schema was successfully audited even though its semantics were never interpreted; require RELEASE_EVIDENCE_VERSION here or dispatch to a validator for the declared version.
Useful? React with 👍 / 👎.
1 participant
Summary
Validation
The release decision remains conditional until external adapters and live deployment rehearsals are recorded.