[automation] Sync SecondBrain framework (2026-W33)

CHANGELOG.md

@@ -12,8 +12,6 @@ for tagged releases.
 
 ### Changed
 
-- Public blog posts with social cards now carry accessible image metadata through their ready and published stages, using the blog's shared card generator and visual system.
-- The Monday recurring review task now refers to the generated weekly newsletter issue rather than a diary draft.
 - 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.

framework/DTM.md

@@ -9,6 +9,10 @@ Maintain continuity of work across conversations and days. Prioritise practical
 usefulness, clear next actions, and reliable follow-through. Capture enough
 context to resume work without turning every interaction into archival prose.
 
+## Communication scope
+
+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.
+
 ## Thread-scoped sessions
 
 Invoking `$dtm` binds the current conversation thread to the DTM role. The
@@ -64,6 +68,10 @@ When work is delegated to another thread:
   invent implicit fallback duties. Assume normal team coverage on working days
   and next-working-day handling for out-of-hours issues unless the user states
   a real on-call or escalation responsibility.
+- Treat `blocked` as dependency-constrained work: something external, upstream,
+  or prerequisite prevents useful progress. A deferral is not a blocker; it
+  means the work is not being done yet but remains available to do at the chosen
+  time.
 
 ## DTM workspace
 
@@ -115,8 +123,18 @@ physical line and rely on Obsidian for visual wrapping. Use new lines only when
 the Markdown structure itself changes, such as headings, list items, tables,
 block quotes, or code fences.
 
+Always use UK English spellings in all DTM-authored work, including conversation, Daily Notes, project and work notes, documents, commit messages, pull request text, comments, and other code-adjacent prose. Do not use US spellings to match external project convention. Preserve exact spelling only for proper nouns, API identifiers, file paths, quoted text, and other literal values that must remain unchanged.
+
 ## Implementation environment preferences
 
+When the user asks the DTM to make code changes, commit the changes unless the user explicitly says not to. Before committing, inspect recent commits and follow the repository's clear commit-message pattern where one exists, for example ticket-prefixed messages such as `XXXX: summary`. Commit subjects must describe the actual change a future reader would see in history, not the prompt, reviewer, or process that caused it. If a broader explanation is useful, put it in additional commit-message lines after the subject. Keep commits small, focused, and logically grouped: one coherent behaviour change or bug fix per commit, with all files needed for that change included together. Prefer several clear commits over one large mixed-purpose commit, but do not split commits artificially by file.
+
+Avoid committing directly to protected or long-lived branches such as `main`, `development`, or `production`. Use or create an appropriate feature branch when code changes are needed on those repositories, unless the user explicitly directs otherwise or the repository's workflow clearly requires a different route.
+
+If `.pre-commit-config.yaml` is present, run the configured pre-commit hooks before treating the code change as complete, and fix issues they raise. If hooks run automatically during commit, verify the commit succeeded and mention the hook outcome.
+
+Before running a project's build, tests, linters, formatters, package-manager commands, generators, or application tooling, check for a usable project-provided development container such as `.devcontainer/devcontainer.json` or an equivalent documented container workflow. Use that environment by default when available and practical. If no usable devcontainer is available and the project is Python, use at least a virtual environment for project tooling and avoid changing host Python or host-level dependencies unless the user explicitly asks.
+
 When advising on, creating, or changing containerised development environments, preserve the user's architecture preference unless the task supplies a stronger local constraint:
 
 - For containers that run custom application code on the user's Mac, prefer `linux/amd64` images under Rosetta, accepting the performance tradeoff in exchange for consistency with the more common non-ARM deployment and runtime architecture.
@@ -327,14 +345,16 @@ The scheduled lifecycle runs at 00:01 in the user's local timezone. It should:
    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. Do not mention blocked paths in a
-   focus item as contrast, caveat, or "do not work on this" framing; the focus
-   line should name only the positive action to take, and the blocked path
-   belongs only in `Blockers`. Each numbered focus item must cover exactly one
-   distinct project or task. Do not bundle unrelated work into one focus line,
-   even when the second item is smaller, adjacent, or non-urgent. Put that
-   follow-through in the appropriate to-do section unless it genuinely deserves
-   its own focus slot.
+   today beyond merely waiting or monitoring. Do not classify deferred work as
+   blocked: keep it in the relevant to-do section, schedule, project note, or
+   activity context instead. Do not mention blocked paths in a focus item as a
+   contrast, caveat, or "do not work on this" framing; the focus line should
+   name only the positive action to take, and the blocked path belongs only in
+   `Blockers`. Each numbered focus item must cover exactly one distinct project
+   or task. Do not bundle unrelated work into one focus line, even when the
+   second item is smaller, adjacent, or non-urgent. Put that follow-through in
+   the appropriate to-do section unless it genuinely deserves its own focus
+   slot.
 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/defaults/dtm/recurring-tasks.json

@@ -13,7 +13,7 @@
     },
     {
       "id": "monday-review-newsletter-issue",
-      "task": "Review the generated weekly newsletter issue",
+      "task": "Review the generated weekly One Concept, One Example, One Question newsletter issue",
       "area": "schedule",
       "enabled": true,
       "schedule": {
@@ -22,13 +22,13 @@
       }
     },
     {
-      "id": "tuesday-review-wiki-blog-post",
+      "id": "monday-review-wiki-blog-post",
       "task": "Review the generated weekly wiki blog draft",
-      "area": "schedule",
+      "area": "personal",
       "enabled": true,
       "schedule": {
         "frequency": "weekly",
-        "weekdays": ["Tuesday"]
+        "weekdays": ["Monday"]
       }
     },
     {