[instructions] Split experimental ledger docs out of memory.md

memory.md had grown to 407 lines, over the 400-line instruction-file
cap, after recent repo-memory JSON-schema-validation changes (#67439).
Extract the self-contained "standalone ledger (experimental)" section
into a new ledger.md, replacing it with a short pointer. Update the
cross-reference in memory-stateful-patterns.md to link directly to
ledger.md instead of an anchor inside memory.md.

debug-agentic-workflow.md is also over the cap (432 lines) after
recent model/engine-misconfiguration diagnostics (#67488), but its
checklist content is pinned inline by a regression test
(.github/skills/agentic-workflows/tests/test_guidance.py) that also
requires it mirrored in root debug.md, so it is left as a documented
exception rather than split.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: github-actions[bot]

.github/aw/ledger.md

@@ -0,0 +1,68 @@
+---
+description: Experimental tools.ledger — structured, immutable, append-only event history with built-in state-model projections.
+---
+
+# Ledger (Experimental)
+
+Use the ledger for immutable, structured events when each run should add records
+and later runs need to query them. For example, a low-volume audit can append
+one result per scan and query prior results by a stable application-level key.
+Configure `tools.ledger` independently of repo-memory. The legacy
+`tools.repo-memory.ledger` declaration is unsupported. Each ledger has a
+`ledgers/<name>` branch and a disposable read-only SQLite projection rebuilt
+from persisted JSONL shards.
+
+```yaml
+tools:
+  ledger:
+    audit-history:
+      type: log
+      compaction:
+        min-segments: 32
+        max-segments: 32
+```
+
+Declare `type: log`, `set`, `map`, `table`, `counter`, or `notes` for built-in state
+models. Schemas validate operation values, not envelopes; tables require a
+string primary-key field through `key`. Maps expose `ledger_map_put` and
+`ledger_map_delete`; notes expose `ledger_note_add` and `ledger_note_vote`.
+Other types use typed `ledger_append` operations.
+
+Query `state` for current state or `records` for immutable history at
+`/tmp/gh-aw/ledgers/<name>/ledger.db`. For a log, submit `ledger_append` with
+`operation: append` and the event in `value`. Requests are deferred and become
+durable only when the trusted `push_ledger_changes` job succeeds; queued writes
+are not immediately visible in the run's projection. Never edit SQLite or
+canonical ledger files.
+
+Each record is limited to 32 KiB, each shard defaults to 100 KiB, and each run
+defaults to a 10 KiB append budget. Configure per-ledger limits with
+`max-segment-kb`, `max-record-kb`, and `max-patch-kb`. Projection preparation
+inspects at most 1024 canonical files and 100 MiB of history.
+Each writing workflow invocation creates a shard, so a frequently running
+workflow can exhaust the shard limit. Use ordinary repo-memory files for
+replaceable snapshots, pruned baselines, or histories that need more than 1024
+writer shards. Compaction belongs to Agentic Maintenance, never the agent or
+persistence job. Use per-ledger `compaction` settings (`schedule`,
+`min-segments`, `max-segments`) or disable it with `compaction: false`.
+Custom `replay.script`, `replay.config`, and `compaction.script` settings are
+rejected. Ordinary repo-memory `validation.script` remains a separate supported
+file-storage validator.
+
+Removing custom replay does not rewrite history. Existing raw-record ledgers
+can omit `type` and query `records.payload` with SQLite JSON functions. Do not
+add a built-in type to raw history unless every payload already matches that
+type's operation format. Use a new ledger name for a new typed state model.
+See the [ledger replay reference](https://github.com/github/gh-aw/blob/main/docs/src/content/docs/experimental/ledger-replay.md)
+and [compaction guide](https://github.com/github/gh-aw/blob/main/docs/src/content/docs/experimental/ledger-compaction.md).
+
+## Tradeoffs
+
+| ✅ Pros | ❌ Cons |
+|---|---|
+| Persists indefinitely (no expiry) | Produces Git commits — repository noise |
+| Auditable: Git history shows every change | Slower: requires Git clone + push |
+| Survives cache invalidation | Not available for Copilot engine (requires GitHub tools) |
+| Human-readable via GitHub branch UI | More complex setup |
+| Can target a different repository | |
+| Provides immutable structured records and queries | Experimental, append-only, and limited to 1024 shard files by default |

.github/aw/memory-stateful-patterns.md

@@ -138,4 +138,4 @@ after `push_ledger_changes` succeeds. Never modify SQLite or ledger shards
 directly. Use stable application keys to identify duplicate events.
 
 For built-in types, script restrictions, and persistence behavior, see
-[memory.md](memory.md#structured-event-history-standalone-ledger-experimental).
+[ledger.md](ledger.md).

.github/aw/memory.md

@@ -20,7 +20,7 @@ For workflows that **persist state across runs** — deduplication, incremental
 | Track a numeric metric and compare current vs. baseline (runs at least every 7 days) | `cache-memory` ✅ first choice |
 | Long-lived knowledge base visible in PRs and code reviews | `repo-memory` |
 | Baselines that must survive cache expiry (e.g. security findings, dedup lists) | `repo-memory` |
-| Bounded append-only structured event history and built-in current-state projections | Experimental `tools.ledger` |
+| Bounded append-only structured event history and built-in current-state projections | Experimental `tools.ledger` — see [ledger.md](ledger.md) |
 | Human-readable wiki pages for knowledge accumulation | `repo-memory` with `wiki: true` |
 | Persist notes/state inline on the triggering issue or PR | `comment-memory` |
 | Private-preview GitHub Drives backend (enrolled repos only) | `drive-memory` — see [drive-memory.md](drive-memory.md) |
@@ -221,57 +221,10 @@ Compiler creates a separate `push_repo_memory` job with `contents: write`; main
 
 ### Structured event history: standalone ledger (experimental)
 
-Use the ledger for immutable, structured events when each run should add records
-and later runs need to query them. For example, a low-volume audit can append
-one result per scan and query prior results by a stable application-level key.
-Configure `tools.ledger` independently of repo-memory. The legacy
-`tools.repo-memory.ledger` declaration is unsupported. Each ledger has a
-`ledgers/<name>` branch and a disposable read-only SQLite projection rebuilt
-from persisted JSONL shards.
-
-```yaml
-tools:
-  ledger:
-    audit-history:
-      type: log
-      compaction:
-        min-segments: 32
-        max-segments: 32
-```
-
-Declare `type: log`, `set`, `map`, `table`, `counter`, or `notes` for built-in state
-models. Schemas validate operation values, not envelopes; tables require a
-string primary-key field through `key`. Maps expose `ledger_map_put` and
-`ledger_map_delete`; notes expose `ledger_note_add` and `ledger_note_vote`.
-Other types use typed `ledger_append` operations.
-
-Query `state` for current state or `records` for immutable history at
-`/tmp/gh-aw/ledgers/<name>/ledger.db`. For a log, submit `ledger_append` with
-`operation: append` and the event in `value`. Requests are deferred and become
-durable only when the trusted `push_ledger_changes` job succeeds; queued writes
-are not immediately visible in the run's projection. Never edit SQLite or
-canonical ledger files.
-
-Each record is limited to 32 KiB, each shard defaults to 100 KiB, and each run
-defaults to a 10 KiB append budget. Configure per-ledger limits with
-`max-segment-kb`, `max-record-kb`, and `max-patch-kb`. Projection preparation
-inspects at most 1024 canonical files and 100 MiB of history.
-Each writing workflow invocation creates a shard, so a frequently running
-workflow can exhaust the shard limit. Use ordinary repo-memory files for
-replaceable snapshots, pruned baselines, or histories that need more than 1024
-writer shards. Compaction belongs to Agentic Maintenance, never the agent or
-persistence job. Use per-ledger `compaction` settings (`schedule`,
-`min-segments`, `max-segments`) or disable it with `compaction: false`.
-Custom `replay.script`, `replay.config`, and `compaction.script` settings are
-rejected. Ordinary repo-memory `validation.script` remains a separate supported
-file-storage validator.
-
-Removing custom replay does not rewrite history. Existing raw-record ledgers
-can omit `type` and query `records.payload` with SQLite JSON functions. Do not
-add a built-in type to raw history unless every payload already matches that
-type's operation format. Use a new ledger name for a new typed state model.
-See the [ledger replay reference](https://github.com/github/gh-aw/blob/main/docs/src/content/docs/experimental/ledger-replay.md)
-and [compaction guide](https://github.com/github/gh-aw/blob/main/docs/src/content/docs/experimental/ledger-compaction.md).
+For immutable, structured events where each run appends records and later runs
+query them by a stable key, use experimental `tools.ledger` instead — configured
+independently of repo-memory. See [ledger.md](ledger.md) for configuration,
+state-model types, limits, and compaction.
 
 ### Tradeoffs
 
@@ -282,7 +235,6 @@ and [compaction guide](https://github.com/github/gh-aw/blob/main/docs/src/conten
 | Survives cache invalidation | Not available for Copilot engine (requires GitHub tools) |
 | Human-readable via GitHub branch UI | More complex setup |
 | Can target a different repository | |
-| Ledger mode provides immutable structured records and queries | Experimental, append-only, and limited to 1024 shard files by default |
 
 ---