Implement ABI burn-in monitoring before the 1.0 branch cut

Open
  • Is something wrong?
#1,810 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c, github-actions
Domain
ci-cd

Research direction

Start by inspecting the existing ABI gates and platform policy, then review the workflow and ABI contract checks mentioned in the issue; .github/workflows/abi-burn-in.yml was absent at the cited commit. The work needs scheduled/manual monitoring, durable per-cell evidence, deterministic tallying, fixtures, and activation/restart-policy documentation. Done means the listed acceptance checks pass without claiming fixture runs as real burn-in credit; #789 owns the actual 30-day evidence.

Written by the indexing model from the issue text.

Description

p1-high track/abi track/release

Scope and ownership

Implement the ABI burn-in monitor before the release branch is cut. This is the engineering child of #789; #789 retains activation after #685/#746/#1151 and the actual 30-day observation/closeout. The release branch is 1.0, as specified by #685, not the historical release-1.x spelling.

Discovery context

During the 2026-09-22 post-0.70.0 triage, .github/workflows/abi-burn-in.yml was absent at released commit c353350232c35356b34085abf5780a2fcb81e80f. #789 combines workflow implementation with evidence that cannot exist until the real branch cut. Architect and Critic reviewed and agreed to delegate implementation here, preserving the parent's operational acceptance rather than creating a second burn-in owner.

Implementation boundary

  • Reuse existing ABI gates and platform policy to implement scheduled/manual monitoring and durable evidence.
  • Record UTC date, exact tested SHA, intended branch, required matrix cells, and per-cell outcomes.
  • Provide deterministic tally/reporting logic and documented activation after the actual cut.
  • Define duplicate-run and missing-day handling explicitly; do not invent a restart waiver. The parent's maintainer-selected restart policy remains explicit, and failed/skipped/missing runs never earn green-day credit.
  • Do not cut the release branch, change its protections, introduce new ABI guarantees, or count fixture runs as release evidence.

Acceptance criteria

  • Scheduled/manual workflow and reporting code exist and use the canonical 1.0 branch.
  • Missing branch, missing tools, failed, skipped, incomplete, or wrong-SHA matrix evidence cannot count as a green day.
  • Fixtures cover day boundaries, duplicate runs, missing days, incomplete cells, failure reporting, and tally behavior.
  • A manual pre-cut fixture/control verifies the implementation without claiming real burn-in credit.
  • Activation and restart-policy documentation identify #789 as owner of the real 30-day evidence.
  • Appropriate workflow/ABI contract checks pass; required ABI coverage is preserved.

Target: 0.90.0 preparation. This target does not require delaying independently ready work until earlier milestones close.

Dominant language
C
Stars
18
Forks
2
Avg merge
10h 5m
Merged PRs (30d)
146

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from semantic-reasoning/wirelog

All issues in semantic-reasoning/wirelog

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.