docs: add shared operational memory under .claude/memory - #678
Conversation
Version-controlled, repo-portable operational notes for working on this repo with Claude Code: gh tooling habits, git hygiene, unattended-loop permission discipline, and the activity-policy ownership model. These are the public, non-sensitive subset of operating knowledge — no credentials, cluster names, project IDs, or internal incident detail. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Considering this in a public repo. RFC. |
kevwilliams
left a comment
kevwilliams
left a comment
There was a problem hiding this comment.
activity-policies-owned-by-source-repos.md's "known latent bug pattern" doesn't hold up: it claims an unguarded link(audit.responseObject.metadata.name, audit.objectRef) recurs across iam/resourcemanager create policies. Checked every created X summary in config/services/activity/policies/{iam,resourcemanager}/*.yaml (user, group, role, serviceaccount, organization, project) — all already wrap it in has(audit.responseObject.metadata.name) ? ... : ... fallback chains, so the DLQ-leak scenario described isn't currently reproducible. (There are unguarded link(audit.responseObject...) calls in userinvitation-policy.yaml, but for accept/decline/cancel transitions, not the "rejected create" case the note describes.) Publishing this as-is would send a future session chasing a bug that's already fixed. The rest of the paths/commands (activity policies directory, gh body-file, sub-issues GraphQL) check out fine and nothing sensitive is exposed — please just correct or drop that bug-pattern paragraph.
Pull request was converted to draft
The iam and resourcemanager create policies already guard responseObject access, so the note no longer describes a live DLQ leak. Keep the rule to guard that access and point at the existing fallback shape. Claude-Session: https://claude.ai/code/session_01QV419URMnKWckY8s6j4Dwi
3 participants
Summary
Every Claude Code session on this repo rediscovers the same handful of tooling habits and one piece of milo-specific architecture, because nothing in the tree records them.
This adds a small version-controlled memory next to the agent config, one file per fact plus an index, covering the GitHub CLI habits that keep issue bodies rendering and sub-issues reachable, keeping a local main current, running an unattended loop without permission prompts, and where this repo's ActivityPolicy resources live and how they ship.
Everything environment-specific stayed out, so there are no incident catalogues, cluster names, project IDs, credentials, or deploy-repo paths.
The ActivityPolicy note overlaps the area #679 touches, so review that entry against it.
Test plan