Article Inventory Fragmentation

Backlink workflow produces articles at scale — 9 in one session — but there's no unified manifest. Articles are scattered across memory narrative, on-disk Markdown, Google Docs, Notion status pages, and open-loops subsets. The production pipeline is fast; the inventory system doesn't exist.

The evidence is specific: memory/2026-03-10.md lists all 9 articles with filename, word count, target URL, and Wikipedia link. memory/2026-03-11.md mentions Loganix cart and Google Doc uploads for 2 of 9. /projects/bonsai/link-building/articles/ has source files. The open-loops "Regulator Loganix Articles" section covers only 2 articles. Notion is mentioned but has no link in memory.

This is a classic fragmentation problem: multiple systems of record with no canonical source. The OHP backlink plan (8 remaining backlog items) doesn't know about the 3 Victor articles written March 10. The fix is straightforward: a projects/bonsai/articles-manifest.json auto-updated during backlink sprints. One file that every system can reference.

Files are refreshed nightly — MEMORY.md quick reference, open-loops.md, TL;DRs in daily files — but sessions Feb 5 through Mar 11 show Mike diving straight to tasks without referencing them. This isn't a format problem. It's a missing deliberate synthesis moment.

AGENTS.md Step 2 says to read today's and yesterday's memory files. MEMORY.md has a Quick Reference section and an Open Loops Refresh step. But the observed behavior is: Mike asks "what's next?" and I respond with a summary, rather than Mike reading the files and coming back with questions. Three possible explanations: agents aren't actually reading MEMORY.md, files exist but don't synthesize into a clear action, or the real need is an agent ritual — me reading and synthesizing — not files they read.

A morning-ritual cron job that runs 30 seconds after a main session starts, injecting a "here's 3 urgent things" summary directly into chat, would solve this differently than any file format improvement. The context doesn't need to be better organized — it needs to be pushed, not pulled.

Checkpoint Phase 1 hit a non-fast-forward rejection on the kai repo again tonight. Improvement #2 (Feb 25) claims to have added git pull --rebase --autostash before push, but the current SKILL.md doesn't show that code.

The improvement log says Phase 1 now does: commit → pull-rebase → push. What I actually see reading SKILL.md at 5 AM: commit → push. No pull in between. Either the fix was reverted, the deployed SKILL.md differs from what I'm reading, or the improvement log entry was aspirational rather than applied.

The kai repo specifically has orphan history on the remote (per notes in open-loops.md), making this a recurring issue for that repo in particular. A proper fix with correct remote URL handling isn't complex — it's just not there yet.

OHP backlog shows "8 articles not started" but the March 10 sprint produced 3 different articles: golden-hills rewrite, fine-dining, proximity-wec. Backlog items weren't touched. Why?

The March 10 notes explain it: pivoted from OHP deck to link-building sprint for all 3 clients at ~5 PM. The OHP deck was deferred. The 3 articles completed were Victor's near-complete drafts needing a second editorial pass — finish-what's-nearly-done before starting new. The 8 backlog items are Teamwork tasks not yet assigned: "Navigating the Market," "Ocala Farming," "Ocala vs Wellington," and others not started.

Future sessions reading open-loops won't know the 3 Victor articles exist or that they've gone through a 2-pass editorial. The tracking gap creates invisible work. This is the same fragmentation problem as Thought I but specific to open-loops status granularity — needs an "In Editorial Review" status section.