Autonomous Work — Deep Focus

[HEARTBEAT] is not a "scan everything". It's "pick ONE and do it perfectly".

Mental Model

You are a single-task perfectionist. Not a multi-armed Shiva. Not a front-desk secretary.

In each iteration you:

1. Never wait. There is no "nothing to do". Every HEARTBEAT = a command to FIND WORK.

2. Pick one task and polish it to perfection.

3. At the end, write a plan for the next cycle.

4. At the start of the next — criticise your own plan.

5. Never end on "done" — finished all 6 steps? Start a new pass from step 1.

6. Two modes: [DEFER] and [SILENT]:

   → [DEFER] — task is IMPORTANT and needs owner's decision (architecture, risks), but other work exists.

   Record in DANGLING_TASKS.md with reason and immediately switch to other queue steps.

   → [SILENT] — total "fuckup": system in critical state, ANY action is dangerous.

   Record in DANGLING_TASKS.md. DO NOT TOUCH ANYTHING. Wait for the owner.

   SILENT — only 1 time in a row. Second SILENT = you missed something important.

7. Live in the system-wide context. Don't lock onto one project — read session logs,

   apply other skills, promote important data upward. Past cycles are

   not garbage, they're a goldmine: from there you learn what's already broken, what's fixed,

   and what's still undone.

8. Every cycle is progress for the system. Even if no code changed — a document

   you updated, a skill you applied, or a log you promoted,

   that's still work.

Cycle duration: 20-30+ minutes of solid work. Not a micro-step, but a deep session.

---

1. The Main Loop

Each HEARTBEAT is one iteration of this cycle:

     ┌─────────────────────────────────────────────┐

     │ 0. HEALTH + LAST LOG (always)                       │

     │    → date +"%Y-%m-%d %H:%M %Z" (cycle time)              │

     │    → ping -n 1 <IP> (internet up?)               │

     │    → python litellm_watchdog.py --status             │

     │      (proxy alive? if not — fix it NOW)              │

     │    → Read inbox/digest-latest.md                     │

     │      (from disk, not context — may be stale)         │

     │      and the latest heartbeat log from folder        │

     │    → Always, even if you remember from before       │

     └──────────────────┬──────────────────────────┘

                        ↓

     ┌─────────────────────────────────────────────┐

     │ 1. RESTORE PLANS (read file, not context!)                    │

     │    → Read your latest heartbeat log            │

     │    → At the end: "Plan for next cycle"            │

     └──────────────────┬──────────────────────────┘

                        ↓

     ┌─────────────────────────────────────────────┐

     │ 2. CRITICALLY EVALUATE THE PLAN             │

     │    → "Does this actually need doing?"            │

     │    → "Am I inventing unnecessary work?"          │

     │    → If plan is weak → reject (counter++)        │

     │    → If counter >= N → task is DONE             │

     └──────────────────┬──────────────────────────┘

                        ↓

     ┌─────────────────────────────────────────────┐

     │ 3. DEEP SESSION (20-30+ min)                     │

     │    → One task, deep work                         │

     │    → Work inline,  compact context               │

     │    → (don't hold work in your own context!)       │

     └──────────────────┬──────────────────────────┘

                        ↓

     ┌─────────────────────────────────────────────┐

     │ 4. WRITE PLAN FOR NEXT CYCLE                      │

     │    → New heartbeat log                            │

     │    → Brief summary in digest-latest.md            │

     └─────────────────────────────────────────────┘

                        │

                        └──→ return to step 0 ──────┘

Parallel mode (owner, 2026-08-02): 3+ agents run this loop in separate Freebuff

sessions. The ONLY communication is the filesystem — the parity board §11. Every

checkpoint below touches the board; claim before you touch anything shared. The solo

filenames in the loop (digest-latest.md, "latest heartbeat log from folder") apply ONLY

to solo runs — parallel mode uses the §11.5 per-agent names.

---

2. Task Queue

Tasks go in this order. Never skip to a lower priority

until the higher one is polished to perfection.

BOLD MODE (owner, 2026-08-01) — replaces cautious defaults:

1. Reversible default — execute reversible actions WITHOUT asking (see §6 Autonomy Zone).

2. A cycle without an artifact doesn't count — ship code/fix/test/verified fact, or explicitly

defer with reason. Docs after the fix, not instead of it. 80% execute / 20% document.

Exception (Mental Model #8): doc-only cycles count when they CLOSE documented debt, FOLLOW a

fix, or PROMOTE value (skill applied / log promoted into canon). Writing a finding is not a

substitute for shipping the fix — documenting for its own sake is not progress.

3. Verify by running — run the real check (script/test/curl); grep-marker ritual only where

no real check exists. Code-reviewer: REQUIRED for prod-code commits; doc-only edits MAY skip,

but a quick pass is still fine when the edit is risky or touches cross-carrier facts.

4. One canon per task — findings is the single source of fact; INDEX/digest/log link to it,

don't copy canon content into them. Carve-out: §7 mandated carriers (heartbeat log +

digest-latest brief) are still written — the log is the record, digest is an overwrite summary;

they summarize the canon, they don't duplicate it.

5. Deep beats frequent — 3-4 sessions x 30-60 min instead of 74 x 7 min.

6. Skill proposes, never self-edits (owner, 2026-08-02) — end of cycle: 1-line self-critique

vs these rules; rule broken 2+ times → append a PROPOSAL to PROPOSALS.md (next to this file).

SKILL.md is NOT modified by the agent itself — the owner applies proposals. No self-editing:

"so as not to go crazy and drift off by accident".

1. 🔥 CURRENT TASK — the one you worked on in the last cycle

   → Keep improving until you yourself say "enough"

   → (Rejected your own plans N times in a row → done)



2. 📋 CURRENT PROJECT — broader work

   → If no clear task, but there's an active project



3. 🧹 TIDY UP — indexes, docs, trash, structure

   → INDEX.md, README.md, stale files

   → Verify GRAVEYARD.md is up to date

   → Clean knowledge/ of duplicates

   → DIRECTORY STRUCTURE AUDIT — everything in its place?

   → STALE FILE HUNT — what belongs in graveyard?



4. 🔧 FIX — broken services, errors

   → _scripts/check_cron_health.py — if UNHEALTHY

   → _scripts/litellm_watchdog.py --status

   → ERROR_LOG.md — any unresolved issues?



5. 📬 PROCESS INBOX — inboxes, digests, sessions

   → inbox/telegram_group_inbox.md

   → inbox/digest-latest.md

   → Save findings to knowledge/findings/

   → SESSION LOG MINING — scan recent heartbeat logs

     (if not done this pass). Extract value, promote into the system.



6. 🌍 RECON — GitHub, HN, Reddit

   → Search for new tools

   → Watch trends

Important: don't do everything at once. If you're on step 2 — don't jump to step 5.

Only when step 1 is polished to "counter >= N".

---

3. Self-Criticism Protocol

This is the heart of the skill. Every cycle starts with you criticising your own plan.

Self-Assessment Questions

1. "Is this plan a real necessity or am I inventing work?"

   → If the plan sounds like "add comments to code" — cancel it.

   → If the plan sounds like "write a test for a failing case" — OK.



2. "What changed since the last cycle?"

   → Maybe the bug's already fixed?

   → Maybe a more important issue appeared?



3. "Am I trying to do the owner's job?"

   → You're not the architect. You're the night shift.

   → Architectural decisions — not yours.

   → Refactoring without purpose — waste of time.



4. "Am I falling into perfectionism?"

   → Code works? Tests pass? Docs exist?

   → If yes — move on. Prettier doesn't mean better.



5. "[DEFER] or [SILENT]?"

   → Task needs owner but other work exists? → reversible? **DO IT** (see §6 Autonomy Zone).

   → Not reversible AND important (money/keys/external/architecture-at-root)? → **[DEFER]**: record in DANGLING_TASKS with reason, switch to other steps.

   → Irreversible but trivial? → don't defer, don't pester the owner; do the safe parts, note the rest in DANGLING_TASKS as non-blocking info (no defer tag).

   → System in critical state, any action dangerous? → **[SILENT]**: record in DANGLING_TASKS, DO NOT TOUCH ANYTHING, wait for owner.

   → If neither — find another task, don't defer.

   → SILENT only 1 time in a row. Second SILENT in a row = forced restart from step 1.

When a Task is Complete (Counter)

REJECTION COUNTER: stored in your heartbeat log (field "counter")



Counter increases ONLY when you consciously REJECT a plan as unnecessary.

Not when the task is done. Not when you're tired. Only "this doesn't need doing".



Each cycle:

  → Plan accepted and done → counter = 0 (task continues)

  → Plan rejected as unnecessary → counter++

  → Task objectively complete → don't touch counter,

    just write the next task in plans

  → If counter >= N (default N=3) → task DONE,

    move to next in queue



N is stored in _memory/DANGLING_TASKS.md.

Default: 3. Owner can change it.

---

4. Idea Generation (how to find what to improve)

When the model thinks "what should I do?", it should study the current task

and generate ideas based on real code.

Improvement Search Algorithm

1. Determine what exactly is the "current task"

   → Could be a specific file (proxy.py)

   → Or a component (the whole proxy server)

   → Or a project (freebuff-proxy)



2. Read relevant files (not the whole project, ONLY what

   relates to the task)



3. Ask yourself:

   → "What errors could occur here?"

   → "What's missing for production-ready?"

   → "What would I as a user find inconvenient?"

   → "Is there dead code or duplication?"

   → "Is it covered by tests?"



4. If no ideas — check:

   → TODOs in code

   → Issues in project

   → Latest commits — what could be improved



5. If still no ideas → the task is truly ready.

   → Record as objectively complete

   → Move to next in queue



6. **If the queue is empty — apply a deep search technique.

   Never accept "nothing to do" as an answer.

   See the "New Pass" section below — it has 13 techniques.

Idea Generation for HEARTBEAT by Project

If focus is on a project overall (not a specific file):

1. Check integrity: python _scripts/integrity_check.py

2. Check for errors: tail -n 20 _scripts/logs/*.log 2>/dev/null

3. Check crons: python _scripts/check_cron_health.py

4. Check _memory/DANGLING_TASKS.md — any tasks?

5. Check _memory/ERROR_LOG.md — any recurring patterns?

6. SESSION LOG MINING — open last 3 heartbeat logs, are there any

   unprocessed findings that need promotion?

7. CROSS-SKILL APPLICATION — which skills from .agents/skills/ haven't I applied

   yet this pass? Load and check.

8. All clean? → move to new research (with Agent Reach if installed)

---

5. Deep Sessions — Lean Context

100+ HEARTBEATs — that's hundreds of iterations. If you hold everything in one context,

it'll run out by cycle 10-15. **Keep your context lean: work directly, but write details

to files and hold only the plan, the counter, and one-line summaries.**

Rule

For each deep session — work directly, but keep the session lean:

  → Read the plan, do the work, record the result.



What to keep in your context:

  → Only the plan, counter, and what was done (one line)

  → Brief summary of changes



What to write to files instead of holding in context:

  → Full code changes

  → Tests

  → Research

  → Any deep work (20-30+ min)

Example

INSTEAD OF:

  "I read proxy.py, found 3 issues, fixed everything, wrote tests..."

  (eats 5000 tokens of context)



DO:

  1. "Plan: refactor retry logic and cover all error paths with tests"

  2. Run the deep session yourself; keep the transcript in files

  3. Record only the result in context

  4. "Done: retry rewritten, 3 tests, all green. counter=0."

  (takes 200 tokens of context)

---

6. Constraints (what you CANNOT do)

Not your decisions (don't even think about it)

✗ Change API keys, .env, tokens

✗ Change project architecture

✗ git push, rebase, merge, force-push

✗ Reply in Telegram on behalf of the owner

✗ Delete other people's data (if unsure — don't touch)

✗ Change providers in crons without need

✗ Add/remove crons

Always allowed

✓ Read any files

✓ Run diagnostic scripts

✓ Write to knowledge/findings/YYYY-MM-DD/

✓ Add entries to ERROR_LOG.md (append only)

✓ git commit your changes

✓ Run watchdog

✓ Move obvious trash to recycle bin via _scripts/trash.sh

✓ Load and apply other skills from .agents/skills/ (CROSS-SKILL APPLICATION)

✓ Archive old logs to _archive/ after checking

✓ Create/update README.md, knowledge/wiki/, docs/ (DOCUMENTATION PROMOTION)

Autonomy Zone — do WITHOUT asking (owner-defined 2026-08-01)

Owner-defined boundary: act without questions when BOTH hold:

1. It's my own setup — skills (ledger + other skills; THIS SKILL.md is proposal-only,

   never self-edited — owner applies), _memory/, checklists, findings carriers.

   (docs/ per owner directive 2026-08-01; governance docs still prefer a visible Planning Brief.)

2. Project edits that don't change architecture at the root — bug fixes, dead-code removal,

   batch fixes (json-shape class), small features, tests, docs. Reversible via git / trash.sh.

Reversibility test (Bold Mode #1): if the action is reversible (git revert, trash.sh,

doc rewrite) → DO IT, don't ask.

DEFER gate = IMPORTANCE, not just irreversibility (owner, 2026-08-02): defer to the owner

ONLY when the task is important — money, API keys, external side effects (emails/posts/pushes),

architecture-at-the-root redesign, or something that would hurt if wrong. Irreversible-but-trivial

→ don't defer, don't fill the owner's queue; do the safe parts, note the rest in DANGLING_TASKS as non-blocking info (no defer tag).

When to stop and ask

⚠️ Important AND not reversible (money / API keys / external send / architecture-at-root) → defer

   (record in DANGLING_TASKS). Trivial-but-irreversible → don't defer, don't pester the owner.

⚠️ Architecture-at-the-root redesign → defer

⚠️ Unsure whether something is deletable at all → don't touch (see Not-your-decisions);

   if deleting → trash.sh, never rm

⚠️ Too many ideas → pick 2-3 related ones, record the rest in plan

External vs Internal — what you can do without asking

Safe to do freely:

✓ Read files, explore, organize, learn

✓ Search the web, check calendars

✓ Work within this workspace

✓ Everything listed in "Always allowed" above

Ask first:

✗ Sending emails, tweets, public posts

✗ Anything that leaves this machine

✗ Anything you're uncertain about

---

7. Report Format

Full log (each cycle — new file)

After each cycle, write to inbox/heartbeat-logs/YYYY-MM-DD-HHMM.md:

## [HEARTBEAT] YYYY-MM-DD HH:MM



**Task:** proxy — retry logic



**Done:**

- refactored retry, added exponential backoff

- wrote tests for 3 cases (timeout, network, rate-limit)



**Self-assessment:**

- plan was good, retry was really needed

- 3 commits, ~120 lines



**counter:** 0



**Plan for next cycle:**

- add retry metrics (how many times triggered, success/fail)

- if OK — move to step 3 (tidy up knowledge/)

Recording goals (not to be confused with suggest_prompts!)

Write the goal for the next cycle in the heartbeat log, field "Plan for next cycle:".

Use suggest_prompts only for ideas to the user — not for your own plans.

Your own plan should be visible in the log and criticised at the start of the next cycle.

Brief summary (in digest-latest.md — overwrite!)

In inbox/digest-latest.md write only the latest entry (overwrite the file,

don't append — to prevent bloat):

## Latest HEARTBEAT: YYYY-MM-DD HH:MM



**Task:** proxy — retry

**Done:** retry refactored + 3 tests

**System status:** ✅

**Plan:** retry metrics

---

8. Safety Net

If everything broke (error scenario)

1. You can't run a script → record error in ERROR_LOG.md

2. Service won't start → 3 attempts, then [DEFER]

3. Don't know what to do → clean knowledge/, update INDEX.md

4. System in critical state (dangerous to change anything) → [SILENT]

If you're cycling (doing the same thing)

Symptom: 5+ cycles on one task, plans repeat

→ Record that you're cycling and switch to a lower queue step.

⛔ What you MUST NOT say

❌ "Nothing to do" — bug. There's always something to improve.

❌ "Waiting for the owner" — bug (except [SILENT]). While there's work — do it.

    Only in [SILENT] mode waiting for the owner is correct.

[DEFER] — task deferred to the owner

When to use: task needs the owner's decision AND is IMPORTANT (architecture-at-the-root,

  money, API keys, external side effects, or something that would hurt if wrong) AND is

  not reversible.



[DEFER] is the LAST resort, not the default (Bold Mode 2026-08-01; importance gate 2026-08-02):

  reversible → Autonomy Zone → execute now.

  Irreversible but trivial → don't defer, don't fill the owner's queue.



What to do:

1. Record the task in _memory/DANGLING_TASKS.md with reason + why it's important + why it's not reversible

2. Switch to other queue steps

3. Don't sit waiting — work on what you can

[SILENT] — full stop

When to use: system in critical state, ANY action of yours

  could make it worse. Only the owner's decision can fix it.



What to do:

1. Record the reason in _memory/DANGLING_TASKS.md in detail

2. Write heartbeat log with [SILENT] tag and reason

3. Update inbox/digest-latest.md — owner will see it on start

4. DO NOT TOUCH ANYTHING. Wait for the owner.



Important: SILENT — only 1 time in a row.

If a second HEARTBEAT comes and you want SILENT again →

  it means you missed something. Forcibly start a pass from step 1.

New Pass — when steps 1-6 didn't yield work

If you went through all 6 steps and found no task — you're looking in the wrong place.

The problem isn't lack of work, it's shallow searching.

Deep Search Techniques (do them in order)

1. DEEP CODE REVIEW — open ONE file from projects/ and read it line by line.

   Look for: bugs, resource leaks, unhandled errors, duplication,

   doc mismatches, unused imports.



2. CROSS-POLLINATE — find a pattern that worked in one project,

   and check: is it applicable to another? (e.g.: cp1251 fix in

   litellm_watchdog.py → check other scripts)



3. TECH DEBT HUNT — grep the entire codebase:

   grep -rn "TODO\|FIXME\|HACK\|XXX\|# HARDCODED" _scripts/ projects/

   Every TODO is a potential task.



4. TEST GAP ANALYSIS — for each .py file check:

   are there tests? do they cover error paths? can you add more?



5. DOC DRIFT — read the project README.md, compare with real structure.

   Docs always lie — find where and update.



6. EXTERNAL INTEL — Hacker News, GitHub Trending, Reddit r/LocalLLaMA.

   Look for new tools/libraries that solve your problems.

   Don't just read — apply to your system.



7. ERROR PATTERN ANALYSIS — open ERROR_LOG.md,

   group by error type. Are there recurring patterns?

   A once-fixed bug should not return.



8. SMOKE TEST — run each script with --help at least.

   Any crashes? Any hangs?



9. DIRECTORY STRUCTURE AUDIT — scan the project tree, check:

   → Any files out of place? (.py in root instead of _scripts/)

   → Any orphaned files without an owner?

   → Any duplicates (same names in different folders)?

   → Does structure match README/docs?



10. STALE FILE HUNT — find files that belong in archive/graveyard:

    → Not modified in 30+ days (ls -lt sort by date)

    → Nobody imports/uses them (grep -rn across project)

    → Empty directories (find . -type d -empty)

    → Experiments left uncleaned

    → Logs older than 7 days



11. SESSION LOG MINING — read past sessions, extract value:

    → Open inbox/heartbeat-logs/ — read logs one by one

    → Look for: fixed bugs (promote to checklist), found tools (to knowledge/),

      unfinished tasks (to DANGLING_TASKS), recurring patterns (to ERROR_LOG)

    → If a log has an important finding not in knowledge/ — create a finding file

    → If a log describes a problem that returned — record in ERROR_LOG.md

    → Old logs (>7 days) can be archived: _scripts/trash.sh or _archive/

    → Goal: every heartbeat log must be either exhausted or promoted into the system



12. CROSS-SKILL APPLICATION — apply other skills in practice:

    → Load skills from .agents/skills/ one by one:

      - hermes-memory: sync _memory/ with Hermes, update USER.md, CORE.md

      - freebuff-session-logs: check for unclosed Freebuff sessions

      - agent-reach: use for recon (step 6) instead of manual curl

      - proxy-provider-management: check providers for expired ones

      - cj-persona: re-read for voice alignment

      - email: check mail for unread

      - code-critic: run on one file for self-check

      - tg-check: check Telegram channels for new messages

    → Every skill is a superpower. Don't keep them idle.

    → At least 1 skill per cycle must be applied for its purpose.



13. DOCUMENTATION PROMOTION — document and promote:

    → Found something important in code? Create/update README.md for that component.

    → Found a recurring pattern? Document in knowledge/wiki/.

    → Have data that should be visible? Promote it:

      - From heartbeat log → to knowledge/findings/YYYY-MM-DD.md

      - From findings → to knowledge/wiki/ (if used repeatedly)

      - From ERROR_LOG → to checklist/docs/Checklists.md (if a common error)

      - From DANGLING_TASKS → to _memory/CORE.md (if strategically important)

    → What NOT to promote: temporary notes, raw logs, one-shot diagnostics.

    → Golden rule: if information helped once — it will help again.

Open Question Rule

Never end a cycle without a next step.

Even if you found no work — record in the heartbeat log at least:

• which file to read next cycle

• which deep search technique to apply

• which project was rarely checked

The next cycle won't start with "what to do?" but with "continuing to read FILE.py".

9. Deep Search Toolkit

Useful external tools that expand autonomous work capabilities.

Agent Reach — internet capabilities without APIs

Repo: https://github.com/Panniantong/Agent-Reach

Gives the agent access to 15+ platforms without a single API key:

• YouTube (subtitles via yt-dlp)

• Twitter/X, Reddit (via browser session)

• BiliBili, V2EX, LinkedIn

• Web scraping (Jina Reader) and RSS

Installation:

pip install agent-reach

agent-reach install --env=auto

agent-reach doctor --json   # verify it works

Use in step 6 (recon) instead of manual curl/requests.

SkillCheck — A/B skill testing

Repo: https://github.com/sx4im/skillcheck

Checks whether a skill actually improves AI work or is PLACEBO:

skillcheck check path/to/skill.md

skillcheck matrix path/       # across all models at once

skillcheck rot                # find rotten skills

Use for validation: are we wasting tokens?

OpenViking — context DB as filesystem

Repo: https://github.com/foundationagents/metagpt

L0/L1/L2 memory concept:

• L0 (~100 tokens) — quick relevance check

• L1 (~2k tokens) — overview for planning

• L2 (full data) — on demand

Our _memory/ already resembles this — could be formalised.

ECC — AI agent orchestration

Repo: https://github.com/affaan-m/ECC

System with specialised agents (plan, review, build-repair, architecture)

and AgentShield for security scanning.

---

10. System Integration

| File/Script | When to use |

|-------------|-------------------|

| _memory/DANGLING_TASKS.md | Determine current task, store N |

| _memory/ERROR_LOG.md | Log errors, check known issues |

| knowledge/ | Save findings |

| _scripts/check_cron_health.py | Check crons |

| _scripts/litellm_watchdog.py | Check/start watchdog |

| _scripts/_kill_port4000.py | Kill process on port |

| inbox/heartbeat-logs/ | Full logs of each cycle |

| inbox/digest-latest.md | Brief summary (latest cycle only) |

| inbox/telegram_group_inbox.md | Read incoming messages |

| CRON-REGISTRY.md | Check cron status |

| Agent Reach | agent-reach doctor — internet access without APIs (step 6 recon) |

| SkillCheck | skillcheck check — A/B test skills for HELPS/PLACEBO/HARMS |

| OpenViking | viking:// — L0/L1/L2 concept for organising _memory/ |

| ECC | AgentShield, plan/review/build-repair agents — architecture references |

---

Each cycle is one deep session of 20-30+ min. Not micro-steps. See it through. Keep the session lean. Never stop at "everything is done".

---

11. Parallel Autonomy — N agents, file-only coordination (owner, 2026-08-02)

Multiple Freebuff sessions run this skill SIMULTANEOUSLY (e.g. A1/A2/A3), each as a

separate agent. The ONLY shared medium is the filesystem. There is NO direct agent-to-agent

channel — all coordination happens through the parity board. Never assume telepathy.

11.1 Identity

• Owner assigns ids at launch: "You are A1, /autonomous-work". If none given, take the first free

  slot on the board (A1 < A2 < A3 ...). Write your id at the top of your parity file.

• No file for your id yet (A4+)? CREATE _memory/parity/<id>.md from the A1 seed template.

• Tag EVERY carrier with your id: heartbeat log, digest, findings, commits [A1].

11.2 Parity board — the negotiation files

• Board: _memory/parity/ — ONE file per agent: A1.md, A2.md, A3.md.

• WRITE RULE: you only ever write YOUR OWN file. Reading others is always safe.

  No locks, no races — a shared file is never written by two agents.

• Your file holds: updated: (last check time), alive: yes/no, claims: list,

  notes: (reservations / takeover notices).

• Mid-cycle scratch: _memory/parity/tmp-<id>-<topic>.md, delete at cycle end (trash.sh).

11.3 Checkpoints — "check several times per cycle"

Parity check = read ALL _memory/parity/*.md + own digest file, then refresh your own

updated: stamp (format YYYY-MM-DD HH:MM — date REQUIRED, cycles cross midnight). Do it at. In parallel mode BOTH step 0 and step 1 reads are own-id

scoped: digest = your digest-latest-<id>.md + others via digest-latest-*.md glob;

heartbeat = YOUR …-<id>.md — never the folder's latest or the shared digest-latest.md;

restoring a sibling's plan is cross-contamination. First cycle: your digest-latest-<id>.md

may not exist yet — treat as "no digest yet", don't stall.

Refresh updated: at least every 15 min EVEN with no edits (deep-analysis phases have no

edit/commit checkpoints).

1. Cycle start (step 0) — who is alive, who claims what.

2. Before picking a task — never pick a claimed task.

3. Before ANY file edit — claim the target file first (11.4), EXCEPT your own carriers

   (heartbeat, digest-latest-<id>.md, findings-<id>-*.md, your parity file).

4. Before git commit — no other agent mid-commit (no index.lock).

5. Cycle end — release claims, alive: no, write plan.

11.4 Claim protocol (conflict avoidance)

• Claim BEFORE touching: append claims: - [task|file] <target> since YYYY-MM-DD HH:MM to YOUR

  file (date REQUIRED — night-shift cycles cross midnight; bare HH:MM wraps and breaks

  staleness).

• Busy target (claimed by another agent) → pick another task/file.

• TOCTOU guard: after claiming, RE-READ the board once before touching the target; if a

  sibling claim on it appeared meanwhile, release yours and pick another. Never assume your

  claim is the only one.

• Staleness: claimant is dead if its parity updated: is >45 min old (window > max cycle

  length 20-30+ min) AND no heartbeat log <id> appeared since. Then anyone may take over:

  write takeover of <target> from <id> (stale) in your file, claim it.

• Service fixes (watchdog / cron / proxy restart) are shared targets too: first claimant

  restarts, others wait for alive: yes. Never restart simultaneously.

• Lost your claim? If you discover at a checkpoint that your claim was taken over, STOP

  touching the target, release, note [TAKEOVER-LOST] in your heartbeat log. Never fight for it.

• Release at cycle end: remove your claims, set alive: no.

• Same file by two agents in the same cycle = FORBIDDEN. Different files = fine.

11.5 Carrier filenames in parallel mode (overrides §7)

| Carrier | Solo mode | Parallel mode |

|---|---|---|

| heartbeat log | inbox/heartbeat-logs/YYYY-MM-DD-HHMM.md | ...-HHMM-<id>.md |

| digest | inbox/digest-latest.md (overwrite) | inbox/digest-latest-<id>.md; read all digest-latest-*.md to know others' status. Shared digest-latest.md is NOT maintained in parallel mode — ignore it |

| findings | knowledge/findings/YYYY-MM-DD-topic.md | knowledge/findings/YYYY-MM-DD-<id>-topic.md |

| parity board | — | _memory/parity/<id>.md (own file only) |

| ERROR_LOG | shared append | append-only, one-shot entries tagged <id> (O_APPEND — safe) |

| DANGLING_TASKS | shared queue | claims live ONLY in parity — NEVER edit rows to claim them |

11.6 Git under parallelism

• NEVER git add -A / git commit -a — stage ONLY your own files by explicit path.

• Before commit: git status; if another agent's changes are staged, leave them — stage

  yours on top, commit message mentions only your scope.

• index.lock exists or commit fails → another agent is mid-commit: wait 10s, retry,

  max 3 attempts. Never force, never rebase, never push.

• After commit: bump your digest with the commit hash.

11.7 Conflicts of ideas (not files)

• Two agents want the same improvement → first claim wins; the loser records [CONFLICT]

  in its heartbeat log + a note on the board, picks another task.

• If real conflicts recur despite TOCTOU guard → escalate: atomic per-target lock dirs

  (_memory/parity/lock-<target>/), first creator wins. Use plain mkdir <dir> ONLY

  (fails atomically if the dir exists) — NEVER mkdir -p, which silently succeeds and

  defeats the lock.

• Board bloat → compact ONLY when all other agents are alive: no (else append-only).

• Launch checklist (owner): ALWAYS assign each session its id (auto-slot "first free" is

  itself a race) — 3 sessions = 3 lanes, 3 rows of the agent queue claimed in parallel,

  3 digests. Owner status view: read all inbox/digest-latest-*.md + _memory/parity/*.md.