PLAN: Document Standards & Institutional Memory

Context

The plan→report workflow has proven itself. The bash standardization project produced four linked documents: plan v1, plan v2, audit report, completion report. Each references its predecessors. Nothing was edited in-place — only new documents were created. Daniel called it "a paradigm shift."

This plan codifies the workflow, upgrades the plan format spec, and propagates institutional memory (like the shebang convention) to all robots.

Origin: report-bash-complete — suggested further actions.

Part A — Upgrade the Plan Format Spec

The current plan format at 1.foo/plan defines the visual elements (steps, stops, decisions, risks, questions) but does not yet document the workflow principles. The following should be added to the spec:

Step 1: Add workflow principles to plan format spec.
New sections to add:

1. Append-only document chain: Never modify a published plan or report. Always create a new document that references the previous one. Documents form an immutable chain: plan v1 → plan v2 → audit report → completion report → next plan.

2. Stop blocks must explain themselves: Every ⏸ STOP must include: (a) WHY we're stopping here, (b) WHAT needs to happen during the stop (review, decision, external input), (c) HOW to continue (what green-lights the next step).

3. Suggested Further Actions: Every report should end with a section proposing next steps, ideas, and institutional memory actions. This is where we ask: "Does this produce institutional memory? Do we need to propagate knowledge to other robots? Are there related problems discovered along the way?"

4. Reports follow the plan format: Reports are the same deck-style HTML as plans, with the same CSS. The difference is the header label (◆ REPORT vs ◆ PLAN) and the badge (COMPLETE/IN PROGRESS vs DRAFT/APPROVED).

⏸ STOP — Show the updated plan format spec to Daniel.

Why: The plan format is a foundational document. Changing it changes how all future work is documented. Daniel should review and approve the new principles before they become the standard.
How to continue: Daniel green-lights the updated spec.

Part B — Propagate Shebang Convention to All Robots

Step 2: Audit which robots have persistent memory of the shebang convention.
Check each robot's system prompt / memory files for any mention of #!/usr/bin/env bash.

Robots that write scripts: Walter 🦉 (MEMORY.md), Walter Jr 🦉, Matilda 🌸. Amy 🐱 uses Python but should know anyway.

⏸ STOP — Report which robots know and which don't.

Why: We need to understand current state before making changes to other robots' memory files.
How to continue: Daniel approves the list of robots to update.

Step 3: Write the shebang convention to each robot's persistent memory.
The convention: #!/usr/bin/env bash always, never #!/bin/bash. Portable, correct, fleet-wide standard.
For each robot: SSH to their machine, append to their memory/config file that gets loaded on startup.

⏸ STOP — Confirm each robot has the convention.

Why: Verify the write stuck. Each robot's memory system is different (OpenClaw MEMORY.md vs Python runtime_context.py vs custom).
How to continue: Verified all, or report which ones failed.

Part C — Update the Text Format (1.foo/text)

Step 4: Revise 1.foo/text — reduce section dividers from 8 to ~4.
Rules to encode in the format itself:
• No single-paragraph sections — merge with neighbors
• No section divider near the end of the document
• Dividers should be spaced with enough content between them to justify the break

⏸ STOP — Show Daniel the revised text before publishing.

Why: The text format is Daniel's writing. Changing its structure changes its voice. He should see and approve the revision.
How to continue: Daniel approves the new version.

Risks

Writing to other robots' memory files (Part B) requires SSH access. Currently 6 machines are unreachable. Only Walter Jr, Vault, Matilda, and Jamie are reachable — but Vault and Jamie aren't robots with memory files. Effectively we can only reach Walter Jr and Matilda.

Each robot has a different memory architecture. Walter/Walter Jr/Matilda use OpenClaw MEMORY.md. Amy uses custom Python (runtime_context.py). Writing to the wrong file means the robot never reads it — the exact "remember to remember" problem Daniel has flagged repeatedly.

Success Criteria

✓ Plan format spec includes workflow principles (append-only chain, stop explanations, suggested actions)
✓ All reachable robots have shebang convention in persistent memory
✓ Text format revised with fewer, better-placed dividers
✓ Every step produced a linked document