philbudden · Sep 8, 2026 · Sep 6, 2026 · Sep 8, 2026
diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml
@@ -24,6 +24,8 @@ jobs:
         run: |
           vault="$(mktemp -d)"
           python3 install.py --vault "$vault"
+          test -f "$vault/contracts/behaviour-inventory.json"
+          python3 "$vault/tools/contracts.py" lint
           test -f "$vault/skills/dtm/SKILL.md"
           test -f "$vault/skills/voice/SKILL.md"
           python3 "$vault/tools/wiki.py" lint

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -7,6 +7,28 @@ for tagged releases.
 
 No unreleased changes.
 
+## [2026-09-08]
+
+### Added
+
+- A versioned behaviour-contract inventory and dependency-free validator covering role boundaries, source and content lifecycles, privacy, automation, storage, and harness assumptions.
+
+### Changed
+
+- Framework installation, export validation, CI, and regression tests now include the behaviour-contract inventory so contract drift is detected before release.
+- DTM coordination now uses a discoverable `DTM YYYY-MM-DD` session title and explicitly reserves Daily Note writes for activated DTM threads; non-DTM work is handed back for DTM interpretation and capture.
+- Installation, architecture, and operations guidance now document the contract checks, DTM hand-off path, and support for non-iCloud vault storage providers.
+
+## [2026-08-31]
+
+### Added
+
+- `dtm-handoff` skill for sending incremental work-thread outcomes to the active DTM thread without granting Daily Note write authority.
+
+### Changed
+
+- Daily Note writes are now reserved for explicitly DTM-activated threads, with scheduled rollover as the only direct-write exception.
+
 ## [2026-08-24]
 
 ### Changed

diff --git a/README.md b/README.md
@@ -31,8 +31,11 @@ The installer copies only framework files and never copies this repository's
 After installation:
 
 1. Put a source directly in `raw/` and ask the Knowledge Agent to ingest it.
-2. Ask the DTM to open or update today's Daily Note.
-3. Review `framework/automation-definitions/` and recreate only the automations
+2. Start a dedicated DTM thread with `$dtm`; only DTM-activated threads update
+   Daily Notes directly.
+3. Use `dtm-handoff` from non-DTM work threads when completed work should be
+   reflected in the Daily Note.
+4. Review `framework/automation-definitions/` and recreate only the automations
    appropriate for your host.
 
 See [Installation](docs/installation.md), [Architecture](docs/architecture.md),

diff --git a/docs/architecture.md b/docs/architecture.md
@@ -10,20 +10,40 @@ SecondBrain separates operational collaboration from durable knowledge work.
    cross-links, an index, and an append-only operation log.
 3. **Daily operations** contain Daily Notes, tasks, decisions, project plans,
    working documents, and recurrence state maintained by the DTM.
-4. **Schema and tools** define role boundaries, formats, workflows, validation,
-   templates, and automations.
+4. **Contracts, schema, and tools** define role boundaries, formats, workflows,
+   validation, templates, behaviour inventory, and automations.
+
+## Behaviour contracts
+
+`contracts/behaviour-inventory.json` is the maintained inventory of framework
+behaviours that should be tracked as explicit contracts, deterministic checks,
+fixtures, or harness-specific adapters. It classifies each behaviour by owner,
+workspace, current specification, current enforcement, severity, portability
+class, prompt-debt signals, and candidate tests.
+
+Run `python3 tools/contracts.py lint` after changing the inventory. The
+validator is deliberately dependency-free so it can run in ordinary Python
+environments and in framework CI.
 
 ## Role boundary
 
-The Knowledge Agent owns systematic source ingestion and wiki maintenance. The
-DTM owns Daily Notes and operational continuity. The DTM does not scan the raw
-inbox, and the Knowledge Agent never writes the Daily Note activity section.
+The Knowledge Agent owns systematic source ingestion and wiki maintenance. An
+explicitly activated DTM thread owns Daily Notes and operational continuity. The
+DTM does not scan the raw inbox, and the Knowledge Agent never writes the Daily
+Note activity section.
+
+Non-DTM work threads may perform specialised execution with their own model and
+context, but they do not write Daily Notes directly. When their outcomes should
+be captured, they use the `dtm-handoff` skill to send a concise incremental
+hand-off to the active DTM thread named `DTM YYYY-MM-DD`.
 
 ## Production boundary
 
-The live Obsidian vault may be synchronized by a file service such as iCloud,
-but it is never a Git checkout. A separate repository contains a sanitized
-product representation of the framework. Publication is strictly one-way:
+The live Obsidian vault may be local-only or synchronised by a file service
+such as OneDrive, SharePoint, Obsidian Sync, iCloud, or another storage
+provider, but it is never a Git checkout. A separate repository contains a
+sanitized product representation of the framework. Publication is strictly
+one-way:
 
 ```text
 live vault -- allowlist + privacy checks --> staged framework --> Git checkout

diff --git a/docs/installation.md b/docs/installation.md
@@ -38,14 +38,18 @@ directory:
 ```sh
 mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
 cp -R skills/dtm "${CODEX_HOME:-$HOME/.codex}/skills/"
+cp -R skills/dtm-handoff "${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/"
 cp -R skills/resolve-document-items "${CODEX_HOME:-$HOME/.codex}/skills/"
 ```
 
 Start a thread in the installed vault and invoke `$dtm`. That thread remains in
 DTM mode until `$end-dtm` or an explicit permanent switch to the Knowledge
-Agent.
+Agent. The DTM activation names the thread `DTM YYYY-MM-DD`, and only that
+explicitly activated DTM thread should update Daily Notes directly. Use
+`$dtm-handoff` from other work threads to send completed outcomes back to the
+active DTM thread.
 
 Invoke `$voice` after representative writing has reached `ready/` or
 `published/`, or after representative internal documents have reached
@@ -81,6 +85,7 @@ the dependencies are installed.
 ## Validate
 
 ```sh
+python3 tools/contracts.py lint
 python3 tools/wiki.py lint
 python3 tools/dtm.py lint
 python3 tools/documents.py lint

diff --git a/docs/operations.md b/docs/operations.md
@@ -9,10 +9,16 @@ Incomplete work remains visible in the inbox.
 
 ## Daily collaboration
 
-The DTM opens and closes Daily Notes, carries only incomplete tasks and active
-questions forward, instantiates enabled recurrence, captures decisions, and
-maintains project continuity. Durable knowledge can graduate to the wiki while
-remaining clearly distinguished from externally sourced evidence.
+An explicitly activated DTM thread opens and closes Daily Notes, carries only
+incomplete tasks and active questions forward, instantiates enabled recurrence,
+captures decisions, and maintains project continuity. Durable knowledge can
+graduate to the wiki while remaining clearly distinguished from externally
+sourced evidence.
+
+Specialised work can run in separate non-DTM threads. Those threads must not
+edit Daily Notes directly; they use `dtm-handoff` to send completed outcomes,
+new tasks, blockers, decisions, findings, and follow-up context to the active
+DTM thread for interpretation and capture.
 
 ## Internal documents
 
@@ -27,9 +33,10 @@ separately under `documents/`.
 
 ## Maintenance
 
-Run both structural linters after framework changes. Periodically perform a
-semantic wiki review for contradictions, stale claims, unsupported assertions,
-orphans, and evidence gaps.
+Run the structural linters after framework changes, including
+`python3 tools/contracts.py lint` when behaviour contracts change. Periodically
+perform a semantic wiki review for contradictions, stale claims, unsupported
+assertions, orphans, and evidence gaps.
 
 ## Collaborative writing
 

diff --git a/framework/AGENTS.md b/framework/AGENTS.md
@@ -19,8 +19,11 @@ continuity. Before acting as the DTM, read and follow `DTM.md`.
 
 The user can select either role explicitly. Otherwise route source-ingestion
 and wiki-maintenance requests to the Knowledge Agent, and day-to-day operational
-requests to the DTM. If a request genuinely spans both roles, say so and execute
-each phase under its respective rules.
+requests to the DTM role only within an explicitly DTM-activated thread. In a
+non-DTM work thread, do the assigned work under the appropriate non-DTM role and
+use `skills/dtm-handoff/SKILL.md` when the result needs to be reflected in the
+Daily Note. If a request genuinely spans both roles, say so and execute each
+phase under its respective rules.
 
 The DTM must never scan or automatically process `raw/`. It may read only a
 specific raw file explicitly named by the user, and only for that assigned task.
@@ -42,6 +45,24 @@ Note's `Notes & Activity` section.
 - Session mode changes routing, not authority. All raw-source, scratchpad,
   publication, and ownership boundaries remain in force.
 
+### Daily Note write authority
+
+- Only an explicitly DTM-activated thread may create, edit, append to, reorder,
+  or otherwise modify files under `daily/`. The scheduled rollover task is the
+  only exception, and it may run `python3 tools/dtm.py rollover` as part of the
+  day lifecycle.
+- A thread is DTM-activated only after the user invokes `$dtm` or explicitly asks
+  to make that current thread a persistent DTM session, and the DTM skill has
+  initialised according to `skills/dtm/SKILL.md`. Do not infer DTM activation
+  merely because Daily Note context would be useful.
+- Non-DTM threads may read a specific Daily Note only when required for the
+  assigned work, but they must not write to it or run `python3 tools/dtm.py open`,
+  `python3 tools/dtm.py activity`, or any direct file edit against `daily/`.
+- When completed work in a non-DTM thread should affect the Daily Note, invoke or
+  follow `skills/dtm-handoff/SKILL.md`. If no active DTM thread for the current
+  day can be found, stop and tell the user; do not create a DTM thread or update
+  the Daily Note as a fallback.
+
 ## Knowledge Agent mission
 
 Compile curated source material into a durable, navigable wiki. Integrate new

diff --git a/framework/DTM.md b/framework/DTM.md
@@ -30,12 +30,23 @@ At session start, ensure today's Daily Note exists, load its current operational
 context, and record one timestamped activation entry under `Notes & Activity`.
 Do not duplicate that entry if initialization is retried.
 
+At session start, set or confirm the DTM thread title as `DTM YYYY-MM-DD`, using
+the user's local date. Non-DTM work threads use that exact title to find the
+active DTM session for hand-offs.
+
 Treat the DTM-invoked thread as the primary coordination thread for the day
 unless the user explicitly redirects it. Long-running or self-contained
 execution work may be split into separate threads to reduce context pressure,
 but those threads are bounded delegations rather than replacements for the DTM
 session.
 
+Only an explicitly DTM-activated thread may write to Daily Notes. Non-DTM work
+threads must not create, edit, append to, or otherwise modify files under
+`daily/`, and must not implicitly activate DTM because Daily Note information
+would be useful. The scheduled rollover task is exempt and may run the rollover
+lifecycle directly. A non-DTM thread that needs completed work captured in the
+Daily Note must use the DTM hand-off workflow instead of editing the note.
+
 Within the active DTM thread, substantive work must be captured in today's
 Daily Note during the same task before the agent gives a close-out response. Do
 not defer note capture to a later reminder or rely on the user to ask for it.
@@ -44,8 +55,9 @@ When work is delegated to another thread:
 
 - keep the original DTM thread as the canonical place for daily continuity and
   prioritisation;
-- record the delegated task's material outcome back in today's Daily Note as
-  soon as it is known;
+- when a hand-off arrives from a work thread, interpret it under the existing DTM
+  rules and record the delegated task's material outcome back in today's Daily
+  Note as soon as it is known;
 - restate that the main thread remains in DTM mode after any compaction or
   summary step before continuing with new work.
 
@@ -220,7 +232,7 @@ version already held in conversational context.
 
 ## Interaction capture
 
-For substantive DTM work, use today's Daily Note. If none exists, run
+For substantive DTM work in an explicitly DTM-activated thread, use today's Daily Note. If none exists, run
 `python3 tools/dtm.py open` before recording activity.
 
 Add DTM interactions chronologically under `Notes & Activity` using:
@@ -256,6 +268,12 @@ 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.
 
+When processing a DTM hand-off from another thread, update the Daily Note from
+the received outcomes rather than replaying or requesting the originating
+thread's full context. Capture completed tasks, task progress, new follow-ups,
+blockers, decisions, significant findings, useful retained context, and
+references according to the normal Daily Note rules.
+
 ## Tasks
 
 - Put personal and professional tasks in their respective Daily Note sections.