Skip to content

Ingest authenticated failed releases into canonical engineering incident authority - #529

Draft
MYLEGND wants to merge 12 commits into
legend/approved-changesfrom
repair/autonomous-release-evidence-handoff-20261007
Draft

MYLEGND wants to merge 12 commits into
legend/approved-changesfrom
repair/autonomous-release-evidence-handoff-20261007

Conversation

@MYLEGND

@MYLEGND MYLEGND commented Oct 8, 2026 •

Copy link
Copy Markdown
Owner

Exact gap

LEGEND's sole release lifecycle emits terminal, authenticated GitHub release evidence, but LegendEngineeringOrchestrator.ProcessIncidentsAsync only reads runtime incidents. Release failures therefore never reach the existing durable engineering work-item/notification system. Raw logs cannot be treated as executable instructions, and a failed candidate SHA is NOT a verified live runtime SHA.

Surgical implementation

  • Extend the existing FounderSoftwareRemediationService GitHub App reader (managed-identity Key Vault credentials, no PAT), using a bounded read-only scan of completed canonical workflow_dispatch release failures. Require exact protected workflow path, approved branch, repository, immutable title/source/authority identity, merged PR source, protected merge ancestry, and exactly one failed terminal release job. Classify the first failed stage from fixed known step labels; NEVER ingest logs or provider error text.
  • In the existing LegendEngineeringOrchestrator.ProcessIncidentsAsync intake, hand authenticated run/candidate/authority/stage values to Infrastructure.Diagnostics.RuntimeDiagnosticStore, the canonical and sole RuntimeDiagnosticIncidents writer. It constructs sanitized evidence, validates exact fixed stages, inserts once with the existing unique fingerprint, and reconciles a concurrent identical insertion without inflating terminal historical observations. The existing LegendEngineeringStateStore.AttachIncidentAsync consumes the incident on the same pass. Existing hosted service already invokes this routine; no new scheduler or workflow.
  • Mark ReleaseVerified=false, SourceFilePath=null, and keep the classified item Tier C until source/production capabilities receive separate governance and live proof. The candidate SHA is provenance only, not the live SHA. A release failure alone cannot authorize CodeX GitHub writes, Founder approvals, a merge or a deployment.
  • Bound scans to five authenticated failures and at most one scan per five minutes. Any unavailable GitHub evidence affects observation only, not release publication, runtime incident processing, or saved reusable validation work.
  • Add focused negative tests for forged identity, wrong branch/repository, fixed stage classification, stable incident dedupe, SQLite once-only persistence, reject arbitrary stage payloads, and no unauthorized repair/liveness.

Locked safeguards

Zero edits to scripts/validation-resume.py, reusable validation parents/children, packaging/evidence IDs, deployment, database schema/migrations, cloud settings, queue admission, release authorizers, security classifications, or existing remediation write authority. Do not broaden SAFE_SOURCE/IntegrityProtected permissions. PRs #525-528 remain untouched and follow their own canonical CI. This PR is a safe release-failure evidence handoff, not a claim that release-control source can auto-repair or that any release deployed successfully.

Proof / no promotion before proof

Protected exact-head architecture/security and all required dependency gates; read-only synthetic GitHub evidence + negative tests, concurrency dedupe, configured service readiness, and distinct live-provenance checks. Keep draft and unmerged until all of these are green. This handoff must fail closed if source lineage or evidence inventory is incomplete.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant