Make the ECC 2.0 GitHub/Linear/handoff/roadmap progress-sync model part of the local observability readiness gate instead of leaving it as roadmap prose only. - add `docs/architecture/progress-sync-contract.md` for GitHub, Linear, handoff, roadmap, and work-items sync - add a `Tracker Sync` check to `scripts/observability-readiness.js` - update observability tests with passing and missing-contract coverage - update observability and GA roadmap docs so the local readiness gate is now 18/18 and records #1848 supply-chain hardening evidence Validation: - node tests/scripts/observability-readiness.test.js (9 passed, 0 failed) - npm run observability:ready -- --format json (18/18, ready true) - npx markdownlint-cli 'docs/architecture/progress-sync-contract.md' 'docs/architecture/observability-readiness.md' 'docs/ECC-2.0-GA-ROADMAP.md' - git diff --check - node tests/docs/ecc2-release-surface.test.js (18 passed) - node tests/run-all.js (2378 passed, 0 failed) - GitHub CI for #1849 green across Ubuntu, Windows, and macOS No release, tag, npm publish, plugin tag, marketplace submission, or announcement was performed.
3.2 KiB
Progress Sync Contract
ECC 2.0 tracks execution state across GitHub, Linear, local handoffs, and the repo roadmap. This contract defines the minimum evidence required before a status update can claim a lane is current.
Sources Of Truth
| Surface | Role | Current rule |
|---|---|---|
| GitHub PRs/issues/discussions | Public queue and review state | Recheck live counts before every significant merge batch and before release approval. |
| Linear project | Executive roadmap and stakeholder status update | Post project status updates while issue capacity blocks issue creation. Create/reuse issues only when workspace capacity is available. |
| Local handoff | Durable operator continuity | Update the active handoff after every merge batch, queue drain, skipped release gate, or blocked external action. |
| Repo roadmap | Auditable planning mirror | Keep docs/ECC-2.0-GA-ROADMAP.md aligned to merged PR evidence and unresolved gates. |
scripts/work-items.js |
Local tracker bridge | Sync GitHub PRs/issues into the SQLite work-items store for status snapshots and blocked follow-up. |
Flow Lanes
The repo mirror uses these flow lanes so ECC work does not collapse into one undifferentiated backlog:
- Queue hygiene and stale-work salvage
- Release, naming, plugin publication, and announcements
- Harness adapter compliance
- Local observability, HUD/status, and session control
- Evaluator/RAG and self-improving harness loops
- AgentShield enterprise security platform
- ECC Tools billing, PR-risk checks, deep analysis, and Linear sync
- Legacy artifact audit and translator/manual-review tails
Each flow lane needs one owner artifact, one current evidence source, and one next action. A lane is not current if any of those three fields are missing.
Significant Merge Batch Update
After a significant merge batch, update Linear and the handoff with:
- Current public queue counts for tracked GitHub repos.
- Merged PR numbers, commit IDs, and validation evidence.
- Changed release gates, if any.
- Deferred or skipped work and the explicit reason.
- The next one or two implementation slices.
When Linear issue capacity is unavailable, use a project status update instead of creating placeholder issues. When issue capacity is available, create or reuse exact-title issues and link them to the repo evidence.
Realtime Boundary
The local realtime path is file-backed by default:
node scripts/work-items.js sync-github --repo <owner/repo>imports current GitHub PR and issue state into the SQLite work-items store.node scripts/status.js --jsonandnode scripts/work-items.js list --jsonexpose local state for a HUD, handoff, or later Linear sync.- Linear remains the external status surface; the repo does not require hosted telemetry to be release-ready.
Hosted telemetry such as PostHog can be added later, but it must consume the same event model rather than becoming a second source of truth.
Release Gate
Do not publish, tag, announce, submit marketplace packages, or claim plugin availability from this contract alone. Release readiness still requires the publication-readiness evidence documents, fresh queue checks, package checks, plugin checks, and explicit maintainer approval.