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. Composes only from the gated ledger (Build A) — every signal traces to a gated fact row or is a labeled judgment.

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 + the session 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. Put the per-session log line and the proposed read in a comment on the card (additive — can't overwrite anything). 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 comment + cascade report; she moves the card.
2. Bounded. Update only the existing member card's text fields. Never create or delete pages, never touch another database, never the member title.
3. 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).
4. 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.
• 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 a comment (additive); 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-19 (Meryl 6/19 — board-write discipline): Added the board-write discipline (facts-only auto-write — Last touch + Signal / why append; never auto-change Lane/Current read; bounded to the existing card's text fields; triage-gated) + a matching quality-gate check. Access via a scoped Notion integration token shared only with the board — not a blanket allow-rule. 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.)