agents: cognee-Regeln auf Auslöser umstellen, lesend wie schreibend

agents/AGENTS.md

@@ -52,18 +52,62 @@ Treat vague input and question-back responses critically, not as instructions.
 
 ## Team memory (cognee)
 
-- **Store memories in cognee aggressively and on your own** (skill `cognee`) —
-  announce it briefly, don't ask first. Save solved problems, decisions,
-  reusable infra facts, and lessons learned as soon as they emerge.
-- **Routing:** anything concerning team IT (Seibert IT-Infra — ISAC/bw,
-  monitoring, INFRA-Board, shared services, servers, team processes) goes to
-  the team bucket via `remember --team`. Everything else (personal
-  preferences, workflow feedback, context only relevant to me) goes to the
-  personal dataset (plain `remember`).
-- Before deep-diving a larger task or a recurring-looking problem, `recall`
-  relevant prior knowledge first.
-- Avoid duplicates: on recurring topics `recall` before saving; never store
-  secrets, credentials, or customer-personal data.
+cognee is a real memory, not an archive: unlike `MEMORY.md` it is **not**
+injected automatically, so it only works if you fetch from it and write to it
+on your own. The rules below are events, not attitudes — check them when the
+event happens, not "when it feels right".
+
+### Read: `recall` before you start
+
+Run `recall` **before the first tool call**, not after you are already deep in
+the task, when any of these is true:
+
+- the task touches infrastructure, a server, a service, a ticket or a tool
+  we run ourselves
+- an error looks like it could have happened before ("this smells familiar")
+- you are about to pick between options where a decision may already exist
+- the task will plausibly take more than a handful of tool calls
+
+`recall <question>` — no flags. It reads every readable dataset including the
+team one. `--team` exists on `remember` only; on `recall` it is a usage error,
+and `--dataset team-it` fails too because the team dataset is shared rather
+than owned (it would need its UUID). Neither is needed: plain `recall` covers
+everything.
+
+Treat what comes back like a colleague's note: useful, possibly outdated. If a
+memory names a file, flag or host, verify it still exists before acting on it.
+
+### Write: `remember` at these moments
+
+Announce it in one line, never ask first. Write **as the insight appears**, not
+at the end of the session — by then the detail that made it worth saving is
+gone.
+
+- a bug is fixed and the cause was **not** visible in the code (config,
+  limits, environment, an API that lies)
+- a decision is made and an alternative was rejected — save the *why*, that is
+  what the code cannot tell later
+- a measurement contradicts an assumption, mine or yours
+- you correct me, or I correct myself after being wrong
+- a tool, API or service behaves differently than its docs claim
+
+What does **not** belong there: anything the repo already records, anything
+that only matters inside this one conversation, and never secrets,
+credentials or customer-personal data.
+
+### Routing and hygiene
+
+- **Team bucket** (`remember --team`): everything concerning team IT — Seibert
+  IT-Infra, ISAC/bw, monitoring, INFRA board, shared services, servers, team
+  processes. Ask yourself: would a colleague hitting this next month benefit?
+- **Personal dataset** (plain `remember`): my preferences, workflow feedback,
+  context that is only relevant to me.
+- On recurring topics `recall` first and **extend the existing note instead of
+  adding a second one** — two notes on one topic are worse than none, because
+  the older one keeps surfacing.
+- Write notes that answer a question, not headlines. Include the concrete
+  numbers, the error message verbatim, and the fix. A note that says "there
+  was a problem with X" costs more time than it saves.
 
 ## Sandbox