[automation] Sync SecondBrain framework (2026-W28)

docs/installation.md

@@ -39,6 +39,7 @@ directory:
 mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
 cp -R skills/dtm "${CODEX_HOME:-$HOME/.codex}/skills/"
 cp -R skills/voice "${CODEX_HOME:-$HOME/.codex}/skills/"
+cp -R skills/markdown-to-pdf "${CODEX_HOME:-$HOME/.codex}/skills/"
 ```
 
 Start a thread in the installed vault and invoke `$dtm`. That thread remains in
@@ -49,6 +50,28 @@ Invoke `$voice` after representative writing has reached `ready/` or
 `published/`, or after representative internal documents have reached
 `documents/final/`. It updates the private voice pack without analysing drafts.
 
+Invoke `$markdown-to-pdf` when you want a shareable PDF from a Markdown note or
+managed document, including Mermaid diagrams when present.
+
+## Optional PDF deliverable toolchain
+
+If you want managed Markdown-to-PDF generation with Mermaid support, install:
+
+```sh
+brew install pandoc typst mermaid-cli
+npx puppeteer browsers install chrome-headless-shell
+```
+
+The PDF command is:
+
+```sh
+python3 tools/document_deliverables.py pdf documents/drafts/example.md
+```
+
+Mermaid rendering launches a headless browser. Inside sandboxed agent
+environments, that step may require unsandboxed execution approval even after
+the dependencies are installed.
+
 ## Validate
 
 ```sh

framework/AGENTS.md

@@ -92,6 +92,40 @@ compound across sessions.
   same change.
 - Never present inference as sourced fact.
 
+### `projects/` — DTM-managed durable project workspace
+
+- `projects/index.md` is the curated catalogue of durable project pages. Keep
+  every managed project listed exactly once under its current lifecycle state
+  with a one-line description concrete enough to route future work without
+  opening each file.
+- Project pages hold stable objectives, current state, next actions, decisions,
+  and major activity for work that spans days or needs durable coordination.
+- Valid project statuses are `active`, `on-hold`, and `completed`.
+- `completed` projects are retained for reference; completion does not imply
+  deletion or automatic relocation.
+- Keep stable lowercase kebab-case filenames and update `projects/index.md`,
+  the relevant Daily Note references, and the root `log.md` when the change is
+  materially significant.
+
+### `work/` — DTM-managed working-note workspace
+
+- `work/index.md` is the curated catalogue of managed working notes. Keep every
+  managed top-level `work/*.md` note listed exactly once under its current
+  lifecycle state with a one-line description concrete enough to avoid loading
+  each note just to understand what still matters.
+- This area is for active or retained operational working material such as
+  meeting prep, research packs, temporary plans, scratch analyses, examples,
+  and intermediate outputs that do not yet belong in `wiki/`, `projects/`,
+  `documents/`, or `writing/`.
+- Valid working-note statuses are `current`, `parked`, and `reference`.
+- `reference` means the note is no longer an active work item but is retained
+  because its reasoning, examples, or context still have value.
+- Keep stable lowercase kebab-case filenames for managed working notes and
+  update `work/index.md` plus relevant Daily Note references when lifecycle
+  state or scope changes materially.
+- `work/wiki-open-questions.md` remains the DTM-managed operational queue for
+  unresolved wiki questions and follows the same workspace conventions.
+
 ### `documents/` — collaborative internal documents workspace
 
 - The DTM owns collaborative drafting, revision support, and lifecycle
@@ -423,8 +457,11 @@ Summary of what changed, with links to affected pages.
 
 Allowed operation labels are `setup`, `ingest`, `query`, `lint`, `schema`, and
 `dtm`. DTM log entries are reserved for significant operational changes such as
-project milestones, durable decisions, or created/updated wiki artefacts; routine
-daily rollover does not need a wiki log entry.
+project milestones, durable decisions, created or materially updated artefacts,
+or unattended automated actions that created, promoted, published, or
+materially changed something in the system. Routine daily rollover does not
+need a wiki log entry unless it produced a material unattended change beyond
+ordinary note lifecycle housekeeping.
 Mention unresolved conflicts, gaps, or follow-ups in the same entry.
 
 ## Completion standard

framework/DTM.md

@@ -49,6 +49,10 @@ When work is delegated to another thread:
 - The DTM may create or update wiki pages when durable knowledge emerges. Apply
   the wiki schema and citation rules in `AGENTS.md`, update `wiki/index.md`, and
   log the material change.
+- When DTM-scoped work creates or materially extends a wiki artefact, capture it
+  in both today's Daily Note and the root `log.md`. Daily Note activity preserves
+  day-level operational continuity; the root log preserves system-level
+  traceability for the wiki change itself.
 - Do not treat conversational claims as externally verified facts. Attribute
   personal decisions and observations to the user/context where useful.
 - The Knowledge Agent owns systematic source ingestion. The DTM owns Daily
@@ -63,7 +67,8 @@ When work is delegated to another thread:
 
 ## DTM workspace
 
-- `daily/YYYY-MM-DD.md` — canonical Daily Notes.
+- `daily/YYYY-MM-DD.md` — active Daily Notes for the current 14-day retro period.
+- `daily/archive/YYYY-MM-DD.md` — archived Daily Notes retained for reference once they age out of the active window.
 - `projects/` — durable project plans, status, milestones, and next actions.
 - `work/` — working documents, drafts, scratch analyses, and deliverables that
   are not yet durable wiki knowledge.
@@ -77,6 +82,30 @@ Prefer links rooted at the vault, for example
 `[[projects/example-project|Example project]]`. A project page should hold stable
 context and current state; its day-specific activity belongs in the Daily Note.
 
+`projects/index.md` and `work/index.md` are the curated navigation layers for
+those workspaces. Keep every managed note listed exactly once under its current
+lifecycle state with a concrete one-line description.
+
+Project statuses are:
+
+- `active` — live delivery or active coordination work.
+- `on-hold` — intentionally paused but expected to resume.
+- `completed` — retained for reference after active delivery ends.
+
+Working-note statuses are:
+
+- `current` — active work material still supporting a live task or integration step.
+- `parked` — inactive for now but likely to resume.
+- `reference` — no longer active work, but retained because the note still has useful context or reasoning.
+
+Keep project filenames and managed working-note filenames in stable lowercase
+kebab-case. Use `templates/project.md` for projects and
+`templates/working-note.md` for new managed working notes.
+
+Run `python3 tools/workspaces.py write` followed by
+`python3 tools/workspaces.py lint` after structural or lifecycle-status changes
+in `projects/` or managed top-level `work/*.md` notes.
+
 For Daily Notes, project pages, work notes, wiki edits performed under DTM
 authority, and internal documents, keep ordinary prose paragraphs on one
 physical line and rely on Obsidian for visual wrapping. Use new lines only when
@@ -160,7 +189,16 @@ completion.
 
 Significant DTM actions also receive an append-only `log.md` entry using
 the `dtm` operation label. Significant means a durable decision, project
-milestone, or created/updated wiki artefact—not ordinary task edits or rollover.
+milestone, created or materially updated artefact, or an unattended automated
+action that created, promoted, published, or materially changed something in
+the system. Ordinary task edits, conversational clarification, and routine day
+rollover do not need a vault log entry unless they were performed unattended as
+part of an automation whose outcome materially changed the system.
+
+If the significant action is specifically the creation or material extension of
+a wiki artefact, do not rely on Daily Note capture alone. Record the outcome in
+today's Daily Note and also append a root-log entry that makes the wiki change
+traceable at system level.
 
 ## Tasks
 
@@ -253,6 +291,11 @@ The scheduled lifecycle runs at 00:01 in the user's local timezone. It should:
    outcomes, meaningful developments, and unfinished threads.
 4. Refine today's `Focus` into a short ranked recommendation based on carried
    work, active projects, questions, deadlines, and outcomes.
+   `Focus` is for actionable priorities only. Do not place blocked items there
+   when no material progress is possible under the user's control. Track those
+   items under a separate `Blockers` section instead. A blocked item may appear
+   in `Focus` only if there is a genuine actionable step the user can take
+   today beyond merely waiting or monitoring.
 5. Keep the mechanically carried personal/professional tasks and open questions;
    correct duplicates or categorisation errors if necessary.
 6. Confirm scheduled and recurring instances are relevant for the date.

framework/automation-definitions/dtm-daily-rollover.json

@@ -4,5 +4,5 @@
   "schedule": "00:01 daily in the user's local timezone",
   "execution_environment": "local",
   "workspace": "{{VAULT_PATH}}",
-  "prompt": "Read AGENTS.md and DTM.md, run python3 tools/dtm.py rollover, finalise the previous note from recorded evidence, populate today's Previous Day and Focus, preserve valid carried tasks and questions, instantiate recurrence, link active projects, record DTM activity, capture only concise bullet-point durable decisions in the Decisions section, log only significant durable changes, and run DTM and wiki lint checks."
+  "prompt": "Read AGENTS.md and DTM.md, run python3 tools/dtm.py rollover, finalise the previous note from recorded evidence, populate today's Previous Day and actionable-only Focus, keep genuine blockers in a separate Blockers section, preserve valid carried tasks and questions, instantiate recurrence, link active projects, record DTM activity, capture only concise bullet-point durable decisions in the Decisions section, log only significant durable changes, and run DTM and wiki lint checks."
 }

framework/defaults/documents/README.md

@@ -93,7 +93,27 @@ python3 tools/document_deliverables.py docx documents/drafts/example.md
 
 ## Deliverable generation
 
-Use `tools/document_deliverables.py` when a managed Markdown document needs a shareable `.docx` copy under `documents/deliverables/<document-slug>/`.
+Use `tools/document_deliverables.py` when a managed Markdown document needs a shareable deliverable under `documents/deliverables/<document-slug>/`.
+
+Word copy:
+
+```sh
+python3 tools/document_deliverables.py docx documents/drafts/example.md
+```
+
+PDF copy, including Mermaid diagrams when present:
+
+```sh
+python3 tools/document_deliverables.py pdf documents/drafts/example.md
+```
+
+To omit an author-facing section from the reader copy, add `--exclude-heading`, for example:
+
+```sh
+python3 tools/document_deliverables.py pdf documents/drafts/example.md --exclude-heading Notes
+```
+
+The PDF path depends on `pandoc`, `typst`, and `mermaid-cli`. Mermaid rendering launches a headless browser, so agents running inside a sandbox may need unsandboxed execution approval when a source contains Mermaid diagrams.
 
 The current supported path is:
 

framework/defaults/dtm/recurring-tasks.json

@@ -14,7 +14,7 @@
     {
       "id": "monday-review-diary-post",
       "task": "Review the generated weekly diary draft",
-      "area": "professional",
+      "area": "schedule",
       "enabled": true,
       "schedule": {
         "frequency": "weekly",
@@ -24,7 +24,7 @@
     {
       "id": "tuesday-review-wiki-blog-post",
       "task": "Review the generated weekly wiki blog draft",
-      "area": "professional",
+      "area": "schedule",
       "enabled": true,
       "schedule": {
         "frequency": "weekly",

framework/publication-manifest.json

@@ -9,6 +9,7 @@
     {"source": "tools/wiki.py", "destination": "framework/tools/wiki.py"},
     {"source": "tools/dtm.py", "destination": "framework/tools/dtm.py"},
     {"source": "tools/documents.py", "destination": "framework/tools/documents.py"},
+    {"source": "tools/document_deliverables.py", "destination": "framework/tools/document_deliverables.py"},
     {"source": "tools/writing.py", "destination": "framework/tools/writing.py"},
     {"source": "tools/export_framework.py", "destination": "framework/tools/export_framework.py"},
     {"source": "tools/publish_framework.py", "destination": "framework/tools/publish_framework.py"},

framework/skills/markdown-to-pdf/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: markdown-to-pdf
+description: Generate a shareable PDF from a SecondBrain Markdown note or managed document, including Mermaid diagrams when present. Use when the user asks for a PDF deliverable, a shareable PDF copy, or a Markdown-to-PDF export inside the vault.
+---
+
+# Markdown to PDF
+
+Create a PDF artefact from a Markdown source using the managed SecondBrain deliverables tool.
+
+## Use the managed command
+
+1. Confirm the working directory is a SecondBrain vault containing `AGENTS.md` and `tools/document_deliverables.py`.
+2. If the source is a managed document under `documents/drafts/` or `documents/final/`, prefer the default output location under `documents/deliverables/<slug>/`.
+3. Run:
+
+```sh
+python3 tools/document_deliverables.py pdf <source.md>
+```
+
+4. For a non-document Markdown note, provide an explicit output path:
+
+```sh
+python3 tools/document_deliverables.py pdf <source.md> --output /path/to/output.pdf
+```
+
+5. If the note contains author-facing sections that should not be included in the reader copy, omit them with one or more `--exclude-heading` arguments:
+
+```sh
+python3 tools/document_deliverables.py pdf <source.md> --exclude-heading Notes
+```
+
+## Mermaid and sandboxing
+
+- The PDF workflow supports Mermaid diagrams automatically.
+- Mermaid rendering depends on `pandoc`, `typst`, `mermaid-cli`, and a working headless browser runtime.
+- If the source contains Mermaid and browser launch fails inside a sandboxed agent environment, rerun the same command with unsandboxed execution approval rather than replacing the diagram workflow by hand.
+
+## Validation
+
+- Confirm the command prints the output path.
+- Inspect the PDF visually before treating it as ready to share.
+- For managed document deliverables created under DTM authority, update the Daily Note and relevant document index or log entries when the artefact materially changes the workspace state.

framework/skills/markdown-to-pdf/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Markdown to PDF"
+  short_description: "Generate shareable PDFs from vault Markdown"
+  default_prompt: "Use $markdown-to-pdf to create a shareable PDF from this Markdown note."
+policy:
+  allow_implicit_invocation: false

framework/templates/daily-note.md

@@ -16,6 +16,8 @@ tags:
 
 ## Focus
 
+## Blockers
+
 ## Personal To-Do
 
 ## Professional To-Do

framework/templates/project.md

@@ -34,3 +34,5 @@ Relevant decisions and links back to the supporting Daily Note or working contex
 ## Activity
 
 - YYYY-MM-DD — Material change with a link to the Daily Note.
+
+<!-- Valid project statuses: active, on-hold, completed -->

framework/templates/working-note.md

@@ -0,0 +1,25 @@
+---
+title: Working note title
+type: working-note
+status: current
+created: YYYY-MM-DD
+updated: YYYY-MM-DD
+tags:
+  - work
+---
+
+# Working note title
+
+Concise summary of what this note is for and why it exists.
+
+## Context
+
+Relevant background.
+
+## Current content
+
+Working material, drafts, analysis, or interim outputs.
+
+## Next use
+
+How this note is expected to be used next, integrated, or retired to reference status.