Repository navigation
Take chg-loop issues as delivery-loop intake: enroll claude-config and chg, measure Gate A on machine intake #986
Description
Mark, 2026-10-16, wants chg (mkreyman/chg) to drive a constant improvement loop across the fleet: collect what's not working and file it as work, automatically. The design is in mkreyman/chg#22 (S14). chg is the sensor and intake writer. loopctl's agent delivery loop is the executor: chg builds none of its own.
loopctl's side:
- Enroll claude-config and chg as intake sources (
intake_source_enroll, plus the Issues webhook), next to home_care_billing. - Triage of
chg-loopissues. They are machine-written and carry evidence: a fingerprint, occurrences, a stated root cause or "unknown, investigate", and acceptance criteria written as checks.- Measure Gate A on them separately from human intake. The expectation, from KB
a08b94b2, is that evidence-carrying issues escalate far less than the 69% human baseline. - Do not relax the gate for them; report the split.
- Measure Gate A on them separately from human intake. The expectation, from KB
- Closure is chg's. chg closes an issue only when the fingerprint stays silent for M days after the merge, and reopens it if the problem recurs. A story reaching
donebecause the issue closed is therefore a verified fix, not just a merge. Make sure a reopened issue re-enters intake rather than being ignored as already done. - Gate B for self-modification. chg's own landing, revert and gate code, and claude-config's safety hooks (deny lists, grant hooks, foreign-repo guard, review counter), must escalate rather than auto-merge. Add those paths to the respective repos' Gate B trigger lists.
Activity
Measure Gate A on chg-loop tickets apart from human intake (US-47.11) (…
A reopened issue re-enters intake as a new generation (US-47.10) (#1010)
mkreyman commentedon Oct 19, 2026
All four items are done and live (Fly v752).
claude-config-delivery,chg-delivery) and target epic, with an Issues-only webhook; both pings returned 200.repo_url, on purpose: the existing KB scopes already carry it, and two projects on one URL makeresolve_projectambiguous.required_checksis empty on both.chg_loopandhumanstrata besideintakeandall, and the gate itself is unchanged.docs/measurements/gate_a_2026-10-19. Itschg_loopstratum is empty because chg has filed nochg-loopissue yet.superseded_by_generation, so it cannot close the recurrence.DELIVERY_GATES_CONFIG, so every change to them escalates with{:unknown_repo, repo}. A test pins this.human_pathsfloor each repo must carry once it gets an entry is stated indocs/agent-delivery-loop.md.4a86157b, because both repos are private.