📖About

The Logbook's own record describes it as a reporting surface, contradicting the rule the Author actually writes to.

MEASURED 2026-08-02 (CLI-201). Ninad restated what the Logbook is for: it conveys design principles for agentic systems; what happened is evidence for the principle, never the subject. Checked that against what is written down:

- The Author's SYSTEM PROMPT already states this, emphatically and in the governing place: "THE LOGBOOK IS A PRINCIPLES BLOG, NOT A CAROLVERSE NEWSFEED (read this twice)", a FLIP TEST ("CORRECT: here is a principle ... and here is how Carolverse ran into it. WRONG: here is a thing that happened ... and here is a lesson from it"), "the principle is the hero; the Carolverse event is merely the evidence", and "you are NOT reporting what happened in Carolverse". Every publishing path goes through this prompt. NO CHANGE NEEDED. - The update-post brief repeats it correctly. NO CHANGE NEEDED. - The app's REGISTRY DESCRIPTION contradicts it: "Palantir-equivalent for Orion: CLI sessions as projects, activities as initiatives, posts in Orion's voice attributing his droids." That describes a reporting mirror of session records — the exact framing the Author is told twice to avoid. It is what any agent or person reads when asking what this app IS, and it is what the grounding layer serves to agent chats. - The new-article brief says "preserve the substance and key examples of the source", which can read as preserving the SHAPE of a source that is itself a status narrative. It already says "follow every rule in your system prompt", so this is a clarification, not a new rule.

WHY IT MATTERS: a record that describes the app as a session-reporting mirror is the kind of stale definition that quietly re-teaches the wrong model — the same class of fault as the pipeline runbook that spent months describing a retired architecture (CLI-161).

SCOPE: 1. Correct the app's registry description to say what the Logbook is for: design principles for agentic systems, illustrated by real Carolverse evidence. 2. Clarify in the new-article brief that the source material is EVIDENCE, not the shape of the post — consistent with the system prompt, adding no new rule. 3. Leave the Author's system prompt and the update brief untouched; both are already correct.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• Current state at filing (Elrond validity check): Orion's Logbook is registered and running, but its registry description still describes it as a session-reporting mirror rather than a principles blog. The Author's system prompt and the update-post brief already state the correct rule, so only the registry description remains inconsistent. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 3 must-have criteria remain pending at bypass_end — delivery FAILED live re-performance; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): test test_ini3588.py: FAIL (no tests ran in 0.36s) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• Anyone or anything asking what Orion's Logbook IS is told it publishes design principles for agentic systems, with Carolverse events as the evidence - not that it mirrors session records as projects and activities. (must_have)
• The Author's system prompt and the update-post brief are unchanged, because both already state the rule correctly. The fix touches only what actually contradicted it. (must_have)
• A commissioned article cannot be steered into a status narrative by its source material: the brief makes clear the source is evidence for a principle, not the shape of the post. (must_have)