Idea
Make incidents a first-class artifact type in Agents Remember: an episodic memory of the repo — its scars and what it went through over time — with each incident anchored by time + commit hashes so the story connects to exact points in the git tree. Any model can then use plain git (log/diff between the anchors) to understand what went down at that time and how the repo evolved from there.
Motivating validation (2026-06-11, device-management)
A real session proved the value of incident knowledge living in memory:
- On 2026-06-03 a GitLab runner incident (apt CA/signature failures, disk exhaustion,
git: command not found in the CI image) was documented in the CI sidecars' bodies and Update History entries, including why the resulting apt-free image design existed and which jobs depend on git describe --tags.
- On 2026-06-10 the whole design was reverted on v1.2.
- During a staleness review on 2026-06-11, the preserved incident knowledge (a) explained the now-reverted design instantly, (b) let the agent recognize the same failure mode re-emerging — the rebuilt CI image once again visibly installs no git — and (c) helped surface a release-breaking leftover (
deploy_azure_tag still building the renamed Dockerfile.dema) before the next production tag fired it.
The knowledge survived only because the sidecar bodies happened to keep the war story and Update History is append-only. There is no dedicated artifact, no anchors, no retrieval path for "what incidents touched this area?".
Sketch (to flesh out later)
- One incident = one durable file, e.g.
incidents/ under the memory root.
- Anchors: timestamps + commit hashes for the relevant lifecycle points (introduced-at, manifested-at, mitigated-at, fixed-at, reverted-at), so each chapter of the story maps to a node in the git DAG.
- Affected scope: source paths / routes touched, plus links to the file-level sidecars (and back-links from sidecars, so war stories no longer have to live inline in bodies where the next rewrite can lose them).
- Retrieval: indexed by the grepai memory provider (semantics: "has anything like this happened before?"); potentially surfaced by drift/context tooling when a change overlaps an incident's anchored paths.
- Lifecycle: append-only timeline entries like Update History; status field (open / mitigated / resolved / reverted-around); c-01 findings-capture could route incident-shaped findings here.
Open questions
- Schema and minimal required fields; what qualifies as an incident vs. a normal finding.
- Relationship to task artifacts (tasks are coordination-local; incidents are durable repo memory).
- Branch semantics and carryover behavior (incidents likely belong to the official line, anchored to landed commits).
- Quality checks: anchor hashes must exist in the repo; timeline ordering.
🤖 Generated with Claude Code
Idea
Make incidents a first-class artifact type in Agents Remember: an episodic memory of the repo — its scars and what it went through over time — with each incident anchored by time + commit hashes so the story connects to exact points in the git tree. Any model can then use plain git (log/diff between the anchors) to understand what went down at that time and how the repo evolved from there.
Motivating validation (2026-06-11, device-management)
A real session proved the value of incident knowledge living in memory:
git: command not foundin the CI image) was documented in the CI sidecars' bodies and Update History entries, including why the resulting apt-free image design existed and which jobs depend ongit describe --tags.deploy_azure_tagstill building the renamedDockerfile.dema) before the next production tag fired it.The knowledge survived only because the sidecar bodies happened to keep the war story and Update History is append-only. There is no dedicated artifact, no anchors, no retrieval path for "what incidents touched this area?".
Sketch (to flesh out later)
incidents/under the memory root.Open questions
🤖 Generated with Claude Code