07 — DETECT SIGNALS (+ send existing shared assets)

Reframed in Phase 1 Build C (2026-06-18). This step USED to "draft Kathryn's deliverables." That is done-for-you by construction, and this kit is advisory-only (file 01 stance invariant) — so producing a new build / recommendation / research doc FOR the member is banned. The step's job is now: detect signals and route them to the member's signal rollup, plus a narrow path to wrap an EXISTING shared asset for sending.

When this step runs

After the member CPM is written (file 06). Auto-advances from there.

Source — read truth, not prose (hard rule). Detect signals from the gated ledger (file 05 Step 5) / the gated claims ([name]-claims-[date].json, which cite the transcript), and the transcript itself where needed. Do NOT source signals from the downstream composed artifacts — the action-items index (this step's own output), the member CPM prose (file 06), or the cascade report (file 10). Those are projections of the ledger; sourcing them projects from a projection and lets soft drift (a transcript "ceiling" quietly becoming a "build need" on the board) ride onto the signal board. Every signal traces to a gated fact row (transcript-cited) or is a labeled judgment built on named fact rows — Build A.

The stance reminder (file 01)

Kathryn does no between-session build work in this kit. So this step does NOT draft a new deliverable, recommendation, research doc, or build FOR the member. A member's build / tooling / infrastructure need is a signal, not a Kathryn to-do. (Rob 6/17: the "shared-file infrastructure recommendation" this step would once have drafted is exactly the violation — it assigned Kathryn a between-session build for a TPC member.)

Job 1 (primary): Detect signals → route to the member rollup

Scan the gated ledger / gated claims (transcript-cited; per the Source rule above) for signals — moments that say a member is moving off baseline (Stay TPC). Three buckets (per the signal-rollup spec):

For each signal:

• Cite it — a gated ledger fact row (transcript-backed), or label it as Kathryn's judgment (the read on top of the facts). Same fact/judgment split as the gate.
• Route it to the member's signal rollup — the member CPM (file 06) + the TPC Member Pipeline Notion board card. NOT to a drafts/ deliverable. (Living-CPM home + automated card moves come in Phase 2; for now, update the CPM + the card.)
• A capability "needs a build" signal becomes an OFFER TRIGGER — a possible deploy sprint / one-time build (paid), or a cross-TPC build. Flag it on the board for Kathryn's read. Never a Kathryn deliverable, never a "we'll build it" line.

Don't force signals. A session can produce zero (the member's steady). That's a valid result — note "no signal change this session."

Board-write discipline (how the card actually gets updated)

When you update the TPC Member Pipeline card, three hard rules (full decision + token setup: business-aos/cyp/tpc/planning/tpc-board-write-architecture-2026-06-19.md):

1. Smallest-risk write; judgment manual. Append the per-session log line and the proposed read as a block on the card body (additive — can't overwrite anything; use API-patch-block-children on the card page). Update only the Last touch property (the one at-a-glance field). Leave Signal / why as Kathryn's curated standing summary — don't auto-append. Never auto-change Lane or Current read — propose the read in the body block + cascade report; she moves the card.

⚠️ Do NOT use the comment endpoint (API-create-a-comment). Under the current board-writer server config (NOTIONTOKEN), it fails closed with missingversion (the Notion-Version header is sent as undefined) — confirmed Tracy 6/24, twice. Every other endpoint (patch-page, patch-block-children, search, query) sends the header fine, so the per-session log routes to the card body instead. (Optional: re-adding the server with the explicit OPENAPIMCPHEADERS form that hard-codes Notion-Version would restore true threaded comments — board-write setup doc Step 3 fallback. Body-append works today with zero reconfig, and it's the robust path — patch-block-children is standard and won't regress on a package bump, whereas the comment endpoint is the proven-flaky one. So it's the default, not a stopgap.) Keep the body log bounded: terse, dated entries; once a card's body log passes ~8 touches, fold the oldest into one collapsed "Earlier touches" toggle so the card surface stays scannable (the one thing comments gave for free).

1. Bounded. Update only the existing member card's text fields. Never create or delete pages, never touch another database, never the member title.
2. Triage-gated. A substantive 1:1 writes facts to the card; a thin call writes a one-line Last touch and stops (file 05 Step 0.5).
3. Never create a card. The scoped token is update-only. If a member has no Pipeline card (a new member), flag it ("no card — create at onboarding") — do not create it. Card creation is a supervised onboarding step, not a cascade action.

Access: through a scoped Notion integration token shared only with the board (least privilege) — never a blanket Notion write grant. Surface the proposed card change in the cascade report (file 10) so there's a record even when auto-written.

Job 2 (narrow): Send-wrapper for an EXISTING shared asset

The only thing this step "produces" for Kathryn is a send wrapper when she's sharing an asset that already exists (a group build, a resource, a framework she built for the cohort) — because sharing-what-exists is not building-for-the-member.

• Locate-existing-asset check (REQUIRED — blocking). If the recap references "the X I built earlier / the framework I shared / the playbook / send [member] the Y," search for the actual asset first (Google Drive archive docs, the vault, prior cyp/tpc/ outputs, prior member drafts). Found → produce a send wrapper (recipient + send date + source link + email body + send instructions + member context), max ~50 lines, NOT a duplicate. Paraphrasing an existing asset is a structural failure.
• If the "asset" doesn't exist yet — it would have to be built — that is NOT a send-wrapper and NOT a deliverable here. It's a capability signal (offer trigger) or out of scope. Do not draft it.

One-off advisory consult

Not a cohort member → no signal rollup. Note any genuine follow-up (a resource to send that already exists → send-wrapper; otherwise a line in the .md). No deliverable drafting.

Outputs

No new "Kathryn deliverable / build" files — that path is removed.

Index template

# [Member Name] — Signals + Actions Index, [YYYY-MM-DD]

**Source session:** `[name]-1on1-[YYYY-MM-DD].md`
**Source CPM:** `[name]-cpm-[YYYY-MM-DD].md`

## Signals this session (→ rollup)
| Bucket | Signal (the read) | Evidence (gated fact / labeled judgment) | Routed to | Offer trigger? |
|---|---|---|---|---|
| capability | needs a shared-file setup the cohort tooling doesn't cover | "we would definitely need the IT team… it's not gonna happen" (gated) | board: Watching + CPM #2 | possible Sprint — flagged |

(or: "No signal change this session — steady.")

## Send-wrappers (existing shared assets only)
- [asset] → `drafts/[slug].md` (links the canonical source)

## Member's / team items (NOT Kathryn's — context only)
[the member's own to-dos from the recap]

---
*Index produced by /draft-1on1-actions (signal-detection mode) in the 1:1 cascade.*

Quality gate

• Every signal traces to a gated ledger fact (transcript-cited) or is a labeled judgment — no ungated assertions.
• Sourced from truth, not prose. Signals were read from the gated ledger / gated claims ([name]-claims-[date].json) and the transcript — not from the action-items index, the CPM prose, or the cascade report. If a "signal" can only be traced to composed prose (not to a gated fact row or a labeled judgment on named rows), it's drift — cut it or re-ground it in the transcript.
• No new Kathryn deliverable / build for the member. If a drafts/ file was produced, it is a send-wrapper for an EXISTING asset — or it shouldn't exist.
• A capability "needs a build" is on the board as an offer trigger, never a Kathryn to-do or a "we'll build it" line.
• Send-wrappers link the canonical source; no duplicated asset content.
• Zero signals is a valid result — say so; don't manufacture one.
• Board write stayed within discipline: session log + proposed read went in an appended card-body block (additive; the comment endpoint is broken — see Job 1 rule 1); only the Last touch property updated; Signal / why / Lane / Current read NOT auto-changed; no page create/delete; via the scoped token, not a blanket Notion grant.

Auto-advance

After updating the rollup + writing the index (+ any send-wrappers), auto-advance to /update-open-actions (file 08).

Change Log

• 2026-06-24 (Tracy 6/24 — board log routes to the card body, not a comment): The board-write comment channel is broken under the current board-writer server config — API-create-a-comment returns 400 missingversion (Notion-Version header sent as undefined), confirmed twice. Re-pointed Job 1 rule 1 + the quality-gate check to append the per-session log + proposed read as a card-body block (API-patch-block-children, which sends the header correctly and succeeded). Same discipline (additive, can't clobber fields, judgment stays human) — different additive channel. Flagged the optional server reconfig (OPENAPIMCP_HEADERS with hard-coded Notion-Version) that would restore comments. Architecture doc updated with the same correction (cyp/tpc/planning/tpc-board-write-architecture-2026-06-19.md). Reason: Kathryn — "I'm not manually adding content there, that's ridiculous"; the cascade must keep the card current automatically, so it can't depend on a broken endpoint.

• 2026-06-21 (source-pinning + Signal / why reconciliation): Pinned signal detection to the gated source. Made explicit (in When this step runs, Job 1, and the Quality gate) that signals are read from the gated ledger / gated claims ([name]-claims-[date].json, transcript-cited) and the transcript — never from the downstream composed artifacts (the action-items index, the CPM prose, the cascade report). Reason: composing a board signal for Rob 6/17, the cascade reached for the action-items index + CPM prose instead of the gated claims — projecting from a projection, which let a transcript "ceiling" (Microsoft read-only + IT-gated SharePoint) lean toward a "build need / possible Sprint" on the card. Also reconciled the 6/19 entry's stale "Signal / why append" language to the comment-based rule — the live Meryl card was found carrying a 6/19 Signal / why append + zero comments, the exact behavior that stale instruction produces.
• 2026-06-19 (Meryl 6/19 — board-write discipline): Added the board-write discipline — facts-only auto-write, judgment stays human: the per-session log line and proposed read go in a comment (additive); only the Last touch property updates; Signal / why stays Kathryn's curated standing summary (not auto-appended); never auto-change Lane/Current read; bounded to the existing card's text fields; triage-gated — plus a matching quality-gate check. Access via a scoped Notion integration token shared only with the board, not a blanket allow-rule. (The first draft of this discipline auto-appended the log to Signal / why; superseded same-week by the comment-based rule — see the 2026-06-21 entry.) Reason: Meryl 6/19 — board writes were erratically blocked by the auto-mode classifier; the right fix is least-privilege + facts-only-auto + judgment-stays-human, not handing the agent standing unrestricted Notion write. Architecture + setup: business-aos/cyp/tpc/planning/tpc-board-write-architecture-2026-06-19.md.
• 2026-06-18 (Phase 1 Build C — file 07 → signal detection): Reframed the step's purpose. It no longer drafts new Kathryn deliverables / builds for the member — that's done-for-you by construction, and this kit is advisory-only (file 01 stance). Primary job is now signal detection (engagement / business-stage / capability) routed to the member's signal rollup (CPM + the TPC Member Pipeline board), with a capability "needs a build" becoming an offer trigger (possible Sprint), never a Kathryn deliverable. Retained the send-wrapper for existing shared assets (sharing what exists ≠ building) + the locate-existing-asset check. Reason: on Rob 6/17 this step would have drafted Kathryn a "shared-file infrastructure recommendation" — a between-session build for a TPC member, exactly the boundary Kathryn flagged. Build C makes that structurally impossible: the file-infra need is now a capability signal / offer trigger on the board, not a deliverable.
• 2026-05-18 (Tracy 5/18 cascade, Pass 2 + Pass 4): Added the Send-existing-asset type + the locate-existing-asset check (blocking when the action item references an existing asset) + the send-wrapper substance test. Reason: Tracy 5/18 produced a paraphrased duplicate of the substantially-complete prompt workflow when the original sat in Kathryn's "2026: TPC Group Session Chat Threads" archive doc. Structural fix: locate-the-asset + send-wrapper. (Retained in Build C — it's the one legitimate "produce something" path: wrapping an asset that already exists.)