Session-log search corpus: greppable offline index of agent session logs #298

New issue

Open

opened 2026-06-26 02:40:35 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-26 02:40:35 +00:00

Owner

Motivation

A critical bit of information lived in coilysiren/inbox and was found only
after a native agent grepped two weeks of session logs. The issue-corpus
work (sibling issues on agentic-os + ward) fixes the issue/inbox half. This issue
captures the other corpus the same incident exposed: agent session logs were
the surface that actually held the answer and the only thing that found it was an
external grep over them.

Question to design

Should warded containers (and Kai) have a greppable, offline index of agent
session logs the same way they will have one for issues? Session logs are a
larger and more sensitive corpus than issues, so this is its own exploration, not
a fold-in:

Where do session logs live and how big is the corpus? What is the retention?
Privacy: logs almost certainly carry private ids, tokens, host identifiers.
Any mounted index must be private and trufflehog-gated, and likely scoped/redacted.
Same discovery-index discipline as the issue corpus: grep to locate, never
treat the snapshot as truth.
Is a git-mirrored corpus the right shape here, or is a search service better
given size and churn?

Exploratory. Capture from a warded architect session. Sibling of the
issue-corpus renderer (agentic-os) and the ward mount issue.

## Motivation A critical bit of information lived in `coilysiren/inbox` and was found only after a native agent **grepped two weeks of session logs**. The issue-corpus work (sibling issues on agentic-os + ward) fixes the issue/inbox half. This issue captures the **other** corpus the same incident exposed: agent session logs were the surface that actually held the answer and the only thing that found it was an external grep over them. ## Question to design Should warded containers (and Kai) have a greppable, offline index of agent session logs the same way they will have one for issues? Session logs are a larger and more sensitive corpus than issues, so this is its own exploration, not a fold-in: - Where do session logs live and how big is the corpus? What is the retention? - Privacy: logs almost certainly carry private ids, tokens, host identifiers. Any mounted index must be private and trufflehog-gated, and likely scoped/redacted. - Same discovery-index discipline as the issue corpus: grep to locate, never treat the snapshot as truth. - Is a git-mirrored corpus the right shape here, or is a search service better given size and churn? Exploratory. Capture from a `warded architect` session. Sibling of the issue-corpus renderer (agentic-os) and the ward mount issue.

coilysiren added the

consult

labels

2026-07-01 04:29:17 +00:00

coilyco-ops added

and removed

labels

2026-07-09 21:39:00 +00:00

coilyco-ops commented

2026-07-09 21:39:39 +00:00

Member

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg

{
  "summary": "## Recommendation\n\nYes, but **not** as a full git-mirrored copy of raw session transcripts.\n\nThe right split is:\n\n- **Give warded containers an offline, greppable discovery index** of session logs.\n- Make that index **small, redacted, and explicitly non-authoritative**, like the issue corpus.\n- Keep the **full session corpus** in a **private query service / ingest pipeline**, not in git.\n\nIn practice, that means:\n\n- **Offline index for containers**: mount a redacted snapshot they can `rg` to answer \"which session mentioned X?\"\n- **Canonical long-lived corpus for Kai**: use the existing session-ingest/search direction (`session watcher -> session-sink -> repo-recall -> luca/session-lattice`), because that shape already matches the churn and privacy profile of transcripts far better than git does.\n\n## What the current repos already say\n\nThere are already **three distinct session-log surfaces** in play:\n\n- **Ward run archives**: `ward` drains exited runs to `~/.ward/agent-logs/<container>/` as `console.log`, `transcript.jsonl`, and secret-free `meta.json`.\n- **Director-safe redacted view**: a parallel `~/.ward/agent-logs-redacted/` tree is mounted read-only into the director surface at `/opt/ward-agent-logs`.\n- **Cross-host Claude session ingest**: Claude sessions live in `~/.claude/projects/**/*.jsonl` per host, and infrastructure already has a watcher that ships them to a central sink for repo-recall-backed querying.\n\nImportant consequences:\n\n- The **incident class in this issue is broader than ward-only runs**. If the answer was found by grepping two weeks of session logs, the useful corpus is likely **all agent sessions across hosts**, not only `ward`'s drained containers.\n- The repos already reject **git as the transport for transcript mirroring** in at least one place: the Syncthing design notes explicitly say transcript files churn too fast for git and produce meaningless history growth.\n- `ward` already treats raw transcripts as **sensitive** enough that the director gets only a redacted sibling, not the raw archive.\n\n## Why a full git corpus is the wrong shape\n\nA full issue-corpus-style mirror of session logs would fight the data:\n\n- **High churn**: transcript files append throughout the session.\n- **Poor git semantics**: append-heavy JSONL is not something humans meaningfully diff or merge.\n- **History bloat**: the same long file changes many times.\n- **High sensitivity**: tool inputs/results can carry secrets, ids, hostnames, repo paths, and other private material.\n- **Parser drift**: transcript format is agent-specific and versioned, unlike issue markdown rendered from a stable API.\n\nThat does not rule out an offline index. It rules out **using git as the raw transcript store**.\n\n## Recommended design\n\n### 1. Canonical source: service-backed private corpus\n\nTreat the service/ingest path as the source of truth for the full session corpus:\n\n- cross-host Claude sessions\n- ward-drained run logs\n- future session-derived rollups\n\nThis is already the direction of travel in the mounted repos. It matches size, churn, and privacy better than git.\n\n### 2. Offline surface: derived redacted discovery index\n\nBuild a **derived** corpus for offline grep. That corpus should be:\n\n- **private**\n- **trufflehog-gated before push/mount**
- **redacted by construction**
- **incremental**
- **explicitly a discovery index, not truth**\n\nA good unit is **one rendered file per session/run**, for example:\n\n- stable metadata: machine/host class, repo, issue, driver, branch, outcome, timestamps, cwd, session id/run id\n- searchable prose extracted from safe fields only\n- maybe capped assistant/user text snippets\n- **no raw tool-result bodies**\n- **no raw tool-call args**\n- clear header telling the agent to confirm with the live/raw surface\n\nFor `ward`-originated runs, the safest seed is the **already-redacted transcript view plus `meta.json`**, not the raw `transcript.jsonl`.\n\n### 3. Keep the discipline identical to the issue corpus\n\nThe mounted snapshot should answer only:\n\n- \"which session likely contains the answer?\"\n- \"which run/repo/issue/host should I inspect next?\"\n\nIt should **not** answer:\n\n- \"what is the final truth?\"\n- \"is this still current?\"\n- \"can I quote this raw transcript body safely?\"\n\nSo the issue-corpus rule carries over cleanly: **grep to locate, then confirm against the live/raw system**.\n\n## Decisions this issue needs\n\n1. **Which corpus is in scope?**\n   My recommendation: not only warded container runs. Include the broader Claude session history, or the index will miss the exact incident class that motivated this issue.\n\n2. **What is the offline artifact?**\n   My recommendation: a **derived redacted index**, not raw transcripts and not a git mirror of append-only JSONL.\n\n3. **What is the source of truth?**\n   My recommendation: the existing private ingest/query path, not the offline mirror.\n\n4. **What gets mounted into containers?**\n   My recommendation: only the **redacted discovery index**, never the raw corpus.\n\n5. **What retention applies?**\n   This needs an explicit policy. Current docs describe container cleanup and log draining, but I did not find a clear retention contract for the drained archive itself. That gap matters before any corpus is scaled up.\n\n## Open questions\n\n- **Scope boundary**: ward-only run logs, or all Claude sessions across Mac/Windows/WSL as well?\n- **Redaction envelope**: is searching only metadata + safe text enough, or would that miss too many needles?\n- **Retention**: how long should raw logs, redacted archives, and the offline index each live?\n- **Freshness/update model**: cron render, event-driven updates, or rebuild from the service corpus?\n- **Mount budget**: how much redacted history can a warded container carry before substrate hydration gets too heavy?\n- **Schema contract**: which agent transcript formats are supported, and how tolerant must the renderer be to format drift?\n\n## Risks\n\n- **Privacy leak** if raw tool I/O reaches the mounted corpus.\n- **False negatives** if redaction strips the exact clue that matters.\n- **Snapshot drift** if agents start treating the offline index as truth.\n- **System duplication** if a git corpus and the existing repo-recall/session pipeline both try to be canonical.\n- **Unbounded growth** if retention is not fixed before rollout.\n\n## Advisory conclusion\n\nThe answer is **yes to offline searchability, no to a raw git-mirrored transcript corpus**.\n\nThe clean shape is:\n\n- **service-backed full private corpus** for durable ingestion and rich querying\n- **derived redacted offline index** for warded containers to grep\n- **same discovery-only discipline** as the issue corpus\n\nThat gives agents the missing capability the incident exposed without turning raw session transcripts into a giant, leaky, high-churn git repo.\n",
  "issues": []
}

Researched and posted automatically by ward agent advisor --harness codex (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. --- pre-commit installed at .git/hooks/pre-commit pre-commit installed at .git/hooks/commit-msg ```json { "summary": "## Recommendation\n\nYes, but **not** as a full git-mirrored copy of raw session transcripts.\n\nThe right split is:\n\n- **Give warded containers an offline, greppable discovery index** of session logs.\n- Make that index **small, redacted, and explicitly non-authoritative**, like the issue corpus.\n- Keep the **full session corpus** in a **private query service / ingest pipeline**, not in git.\n\nIn practice, that means:\n\n- **Offline index for containers**: mount a redacted snapshot they can `rg` to answer \"which session mentioned X?\"\n- **Canonical long-lived corpus for Kai**: use the existing session-ingest/search direction (`session watcher -> session-sink -> repo-recall -> luca/session-lattice`), because that shape already matches the churn and privacy profile of transcripts far better than git does.\n\n## What the current repos already say\n\nThere are already **three distinct session-log surfaces** in play:\n\n- **Ward run archives**: `ward` drains exited runs to `~/.ward/agent-logs/<container>/` as `console.log`, `transcript.jsonl`, and secret-free `meta.json`.\n- **Director-safe redacted view**: a parallel `~/.ward/agent-logs-redacted/` tree is mounted read-only into the director surface at `/opt/ward-agent-logs`.\n- **Cross-host Claude session ingest**: Claude sessions live in `~/.claude/projects/**/*.jsonl` per host, and infrastructure already has a watcher that ships them to a central sink for repo-recall-backed querying.\n\nImportant consequences:\n\n- The **incident class in this issue is broader than ward-only runs**. If the answer was found by grepping two weeks of session logs, the useful corpus is likely **all agent sessions across hosts**, not only `ward`'s drained containers.\n- The repos already reject **git as the transport for transcript mirroring** in at least one place: the Syncthing design notes explicitly say transcript files churn too fast for git and produce meaningless history growth.\n- `ward` already treats raw transcripts as **sensitive** enough that the director gets only a redacted sibling, not the raw archive.\n\n## Why a full git corpus is the wrong shape\n\nA full issue-corpus-style mirror of session logs would fight the data:\n\n- **High churn**: transcript files append throughout the session.\n- **Poor git semantics**: append-heavy JSONL is not something humans meaningfully diff or merge.\n- **History bloat**: the same long file changes many times.\n- **High sensitivity**: tool inputs/results can carry secrets, ids, hostnames, repo paths, and other private material.\n- **Parser drift**: transcript format is agent-specific and versioned, unlike issue markdown rendered from a stable API.\n\nThat does not rule out an offline index. It rules out **using git as the raw transcript store**.\n\n## Recommended design\n\n### 1. Canonical source: service-backed private corpus\n\nTreat the service/ingest path as the source of truth for the full session corpus:\n\n- cross-host Claude sessions\n- ward-drained run logs\n- future session-derived rollups\n\nThis is already the direction of travel in the mounted repos. It matches size, churn, and privacy better than git.\n\n### 2. Offline surface: derived redacted discovery index\n\nBuild a **derived** corpus for offline grep. That corpus should be:\n\n- **private**\n- **trufflehog-gated before push/mount** - **redacted by construction** - **incremental** - **explicitly a discovery index, not truth**\n\nA good unit is **one rendered file per session/run**, for example:\n\n- stable metadata: machine/host class, repo, issue, driver, branch, outcome, timestamps, cwd, session id/run id\n- searchable prose extracted from safe fields only\n- maybe capped assistant/user text snippets\n- **no raw tool-result bodies**\n- **no raw tool-call args**\n- clear header telling the agent to confirm with the live/raw surface\n\nFor `ward`-originated runs, the safest seed is the **already-redacted transcript view plus `meta.json`**, not the raw `transcript.jsonl`.\n\n### 3. Keep the discipline identical to the issue corpus\n\nThe mounted snapshot should answer only:\n\n- \"which session likely contains the answer?\"\n- \"which run/repo/issue/host should I inspect next?\"\n\nIt should **not** answer:\n\n- \"what is the final truth?\"\n- \"is this still current?\"\n- \"can I quote this raw transcript body safely?\"\n\nSo the issue-corpus rule carries over cleanly: **grep to locate, then confirm against the live/raw system**.\n\n## Decisions this issue needs\n\n1. **Which corpus is in scope?**\n My recommendation: not only warded container runs. Include the broader Claude session history, or the index will miss the exact incident class that motivated this issue.\n\n2. **What is the offline artifact?**\n My recommendation: a **derived redacted index**, not raw transcripts and not a git mirror of append-only JSONL.\n\n3. **What is the source of truth?**\n My recommendation: the existing private ingest/query path, not the offline mirror.\n\n4. **What gets mounted into containers?**\n My recommendation: only the **redacted discovery index**, never the raw corpus.\n\n5. **What retention applies?**\n This needs an explicit policy. Current docs describe container cleanup and log draining, but I did not find a clear retention contract for the drained archive itself. That gap matters before any corpus is scaled up.\n\n## Open questions\n\n- **Scope boundary**: ward-only run logs, or all Claude sessions across Mac/Windows/WSL as well?\n- **Redaction envelope**: is searching only metadata + safe text enough, or would that miss too many needles?\n- **Retention**: how long should raw logs, redacted archives, and the offline index each live?\n- **Freshness/update model**: cron render, event-driven updates, or rebuild from the service corpus?\n- **Mount budget**: how much redacted history can a warded container carry before substrate hydration gets too heavy?\n- **Schema contract**: which agent transcript formats are supported, and how tolerant must the renderer be to format drift?\n\n## Risks\n\n- **Privacy leak** if raw tool I/O reaches the mounted corpus.\n- **False negatives** if redaction strips the exact clue that matters.\n- **Snapshot drift** if agents start treating the offline index as truth.\n- **System duplication** if a git corpus and the existing repo-recall/session pipeline both try to be canonical.\n- **Unbounded growth** if retention is not fixed before rollout.\n\n## Advisory conclusion\n\nThe answer is **yes to offline searchability, no to a raw git-mirrored transcript corpus**.\n\nThe clean shape is:\n\n- **service-backed full private corpus** for durable ingestion and rich querying\n- **derived redacted offline index** for warded containers to grep\n- **same discovery-only discipline** as the issue corpus\n\nThat gives agents the missing capability the incident exposed without turning raw session transcripts into a giant, leaky, high-churn git repo.\n", "issues": [] } ``` --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-10 04:03:12 +00:00

ward release race condition #935

coilyco-ops added

interactive

and removed

consult

labels

2026-07-10 08:59:43 +00:00

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283