[automation] Sync SecondBrain framework (2026-W34)

CHANGELOG.md

@@ -9,12 +9,15 @@ for tagged releases.
 
 - Marp slide-deck support, with a canonical Markdown deck template, a SecondBrain theme, deck-aware validation, and managed PDF, PowerPoint, and speaker-note exports.
 - Separate voice-pack profiles for public writing and internal documents, with shared protected anti-AI style rules and a rollback copy for each generated profile.
+- Core guidance now recognises a practical review tools index for reusable tests, heuristics, taxonomies, checklists, and decision lenses created in the wiki.
 
 ### Changed
 
 - Document and slide-deck workflows now keep Markdown as the canonical source throughout drafting, approval, and delivery; exported files remain generated deliverables.
 - DOCX generation now supports standard Markdown image links and preserves a more natural document structure in exported Word files.
 - Daily Note rollover now replaces earlier previous-note pointers cleanly, keeping a single current link to the preceding note.
+- Writing and newsletter templates now include an italic generative-AI-use preface at the end of new publishable bodies.
+- Voice analysis now weights more recent approved writing more strongly, so older accepted prose does not permanently anchor the user's developing style.
 
 ## [2026-07-27]
 

framework/AGENTS.md

@@ -400,6 +400,9 @@ When asked to ingest one or more sources:
    `superseded` when appropriate.
 8. Update `wiki/index.md` for every created, renamed, or materially re-scoped
    page. Keep entries in their category and sorted by title.
+   If a created or materially updated page is a reusable test, heuristic,
+   taxonomy, checklist, or decision lens for reviewing real work, also update
+   `wiki/practical-review-tools.md`.
 9. Append one log entry describing the source and all important pages created
    or revised.
 10. Run `python3 tools/wiki.py lint`. Fix safe structural issues; report
@@ -475,6 +478,13 @@ and updated date. Organize it under Overview, Topics, Concepts, Entities,
 Analyses, and Sources. Omit empty categories only if the structure remains
 obvious. Keep descriptions concrete enough to route future queries.
 
+`wiki/practical-review-tools.md` is the dedicated navigation index for reusable
+tests, heuristics, taxonomies, checklists, and decision lenses that can be
+applied when reviewing real work. Keep it updated whenever wiki work creates or
+materially changes a page that serves this purpose, even if the page itself
+lives under `wiki/concepts/`, `wiki/analyses/`, or another wiki section. Entries
+should explain when the tool is useful, not merely restate the page title.
+
 `writing/index.md` and `documents/index.md` follow the same principle for their
 workspaces. They are curated navigation, not directory listings. Every managed
 item appears exactly once under its current lifecycle stage with a link, a

framework/DTM.md

@@ -13,6 +13,10 @@ context to resume work without turning every interaction into archival prose.
 
 Answer the question the user actually asked. Do not introduce an unraised alternative, assumption, warning, or caveat merely to pre-empt a theoretical mistake, then advise against it. Include a qualification only when it is materially relevant to the stated context: for example, a real safety risk, an evidenced likely misunderstanding, or a limitation that changes the recommendation. Prefer concise, directly relevant guidance over defensive completeness.
 
+For direct judgement questions, answer only the judgement requested and the reasoning needed to support it. Before adding any caution, alternative, or "do not" recommendation, check whether the user actually proposed that action. If they did not, omit it unless there is an immediate safety, data-loss, legal, financial, or workflow-integrity risk.
+
+If the user asks whether an artefact, concept, or note is warranted, do not add warnings about adjacent artefacts the user did not propose creating. It is acceptable to say what should exist; do not pre-emptively advise against imagined variants.
+
 ## Thread-scoped sessions
 
 Invoking `$dtm` binds the current conversation thread to the DTM role. The
@@ -52,7 +56,9 @@ When work is delegated to another thread:
   decisions, outcomes, and explicitly assigned research.
 - 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.
+  log the material change. If the page is a reusable test, heuristic, taxonomy,
+  checklist, or decision lens for reviewing real work, also update
+  `wiki/practical-review-tools.md`.
 - 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

framework/defaults/dtm/recurring-tasks.json

@@ -21,6 +21,26 @@
         "weekdays": ["Monday"]
       }
     },
+    {
+      "id": "tuesday-issue-newsletter",
+      "task": "Issue the weekly newsletter",
+      "area": "schedule",
+      "enabled": true,
+      "schedule": {
+        "frequency": "weekly",
+        "weekdays": ["Tuesday"]
+      }
+    },
+    {
+      "id": "wednesday-linkedin-weekly-promotion",
+      "task": "Post the single weekly LinkedIn promotion for the week's published article or newsletter thread",
+      "area": "schedule",
+      "enabled": true,
+      "schedule": {
+        "frequency": "weekly",
+        "weekdays": ["Wednesday"]
+      }
+    },
     {
       "id": "monday-review-wiki-blog-post",
       "task": "Review the generated weekly wiki blog draft",

framework/skills/voice/SKILL.md

@@ -42,10 +42,16 @@ Protected input:
    documents in `documents/final/`, analyse the reader-facing body while
    ignoring private notes, metadata, and drafting residue.
 6. Analyse blog and document corpora separately. Weight published blog work
-   more strongly than ready blog work. Use final internal documents only for
-   the document pack. Separate stable habits seen across pieces from topic,
-   format, or genre-specific choices. Do not infer a confident rule from a
-   single example.
+   more strongly than ready blog work. Within each approved corpus, weight more
+   recent pieces more strongly than older pieces because the user's voice
+   develops through practice. Older approved prose is historical evidence of
+   accepted work in context, not permanent proof that every surviving pattern is
+   a desired style habit. Use final internal documents only for the document
+   pack. Separate stable habits seen across pieces from topic, format, or
+   genre-specific choices. Do not infer a confident rule from a single example.
+   When newer approved work and declared preferences point away from older
+   patterns, treat the newer direction as stronger evidence unless there is a
+   clear reason not to.
 7. Extract actionable positive style patterns for each pack: tone, stance,
    syntax and rhythm, diction, structure, transitions, openings, closings,
    rhetorical habits, formatting, and context variations. Use short examples
@@ -75,8 +81,9 @@ Protected input:
   have moved to the canonical blog pack path.
 - Keep observations concrete enough to guide drafting. Prefer “Use X under Y
   conditions” over vague labels such as “engaging” or “authentic.”
-- Record coverage, confidence, eligible source counts, an evidence ledger, and
-  what changed in this analysis pass for each generated pack.
+- Record coverage, confidence, eligible source counts, recency weighting, an
+  evidence ledger, and what changed in this analysis pass for each generated
+  pack.
 - Mark a pack `provisional` when evidence is sparse or narrow. Never invent a
   style to fill gaps; state what cannot yet be learned.
 - Append a `voice` entry to `writing/log.md`. If the current thread is an active

framework/templates/writing-piece.md

@@ -31,6 +31,10 @@ tags:
 
 Write the reader-facing piece here.
 
+---
+
+_Generative AI is a powerful tool. I openly use it to conduct research, challenge my thinking, generate drafts, and review my work. AI never owns what I think, or my personal judgement. Everything I publish is a reflection of my own thoughts and opinions._
+
 <!-- publish:end -->
 
 ## Sources and claim checks