Roadmap.
28 active features (+ 9 retired). From research artefact to multi-engagement product.

F1 Hosted-Postgres migration (Azure Flexible Server, schema-per-engagement)

Move the audit spine and all peer-ring tables from local Postgres on Charlie's laptop to Azure Database for PostgreSQL Flexible Server in a single migration that is multi-engagement-capable from day one.

Why

Removes the laptop SPOF, eliminates the dab-config.json connection-string secret on disk, and unblocks every cross-engagement, off-laptop, and portfolio item downstream. With DR ruled out (F25), getting the spine off the laptop is the only durability story.

What gets built

• Azure PostgreSQL Flexible Server, UK South, B2ms tier (~$80–$120/mo idle).
• Entra ID auth via Managed Identity for the DAB container. No connection-string-on-disk.
• Private endpoint into the default VNet. DAB co-located in Container Apps in the same region (avoids per-call cross-WAN latency on every SP call).
• Schema-per-engagement isolation: Haleon migrates into schema haleon. Future engagements get their own schema (acme, globex, ...) on the same DB.
• Schema-scoped database roles — no "anonymous" role spans schemas. sp_* functions and *In shims replicated per schema with schema-scoped SECURITY DEFINER.
• 72-hour dual-read window post-cutover: read from both local and Azure, sentinel-table count reconciliation before decommissioning the laptop instance.

Cutover mechanics

1. pg_dump --schema-only — review for laptop-isms (file paths in function bodies, extension dependencies).
2. Restore schema to Azure.
3. pg_dump --data-only of the haleon schema — restore.
4. DAB cutover: feature-flag in workflow.json points the MCP transport at the new host.
5. Operator and peers pick up at next bootstrap.
6. Run a 2-hour read-only freeze on a Saturday morning UK time when scout activity is minimal.

New failure modes to handle

Entra token expiry mid-transaction (DAB needs token refresh); connection-pool exhaustion under rapid scout sweeps; Azure PG maintenance window (pin a Sunday 02:00 UTC slot); network partition between Operator session and Azure (peers need graceful "DAB unreachable" degradation, not silent failure); Azure DB running-cost line (~$80–$300/mo) needs its own Azure budget alert as a sibling to the in-DB breaker.

F2 Off-laptop durable scheduler (Container Apps Jobs)

Collapsed. Originally proposed lifting all crons (ring-tick, scout-sweep, daily-brief, ado-scribe drainer) to Container Apps Jobs. The constraint that all external-source reads and LLM cognition must run under Charlie's authenticated identity in Clawpilot (31 May ruling) eliminates everything except pure-DB operations from the off-laptop candidate list — and the pure-DB candidates (cost rollup, breaker check, verify-chain, gap-scan) all have the property that nothing meaningful happens to the DB when the laptop sleeps (no writes ⇒ no rollups to compute, no chain to verify beyond the last state). Container Apps Job infrastructure is not justified for catching-up-at-next-wake operations whose work was zero in the interval.

Replacement: cron remains in Clawpilot, hosted by the Steward peer as a scheduling loop that fires on each interactive session resume. See F26 for the always-on-while-awake successor to scout sweeping.

F5 Kernel-vs-engagement-pack manifest + contracts grep-test

Codify the kernel-vs-pack boundary. Every "Haleon-ism" in the kernel becomes a leak that a CI-style grep-test catches.

What gets built

• Written manifest of what is kernel (workflow-agnostic) vs what is per-engagement.
• Engagement pack directory layout: ~/.copilot/m-engagement-packs/<name>/{pack.json, scouts/, briefs/overlays/, secret-refs.json}.
• Engagement-overlay briefs (cos.engagement-overlay.md, sa.engagement-overlay.md) that shadow kernel briefs without overriding invariants.
• Grep-test: enforces zero haleon|otc|hcp|gxp|consumer.health|charlie (case-insensitive) under m-skills/ and m-role-briefs/. Runs at every bootstrap-roles and on any kernel edit.

Closes

Charlie open-Q #6 (SA brief still references MicrosoftMcCormickTesting/Loom).

F6 5-layer configurability + bootstrap validator + config fingerprint

One typed home for every configurable value, in five layers. Fail loud at bootstrap if a required value is missing.

The 5 layers

• L0 — Process env: Key Vault URIs only. Bootstrap reads from env.
• L1 — workflow.json (kernel): peer cardinality, audit transport, rotation rotator-of-record, phase-boundary timestamps, contact-channel transport. No engagement-specific values.
• L2 — Engagement pack (pack.json): customer name, GH org allowlist, MSX territory, intake channel ids, ADO org/project, Teams contact channel id, compliance regime, recipient-voice profile name. No secrets — only KV URIs.
• L3 — cos_config table: runtime-mutable per engagement.
• L4 — Per-skill local config: skill-internal opinions only.

cos_config — the 6 initial keys (locked)

• intake_channels — array, default [] (read by Intake Triage scout)
• intake_customer_names — array, default [] (privacy hard-gate — scout aborts if empty)
• reuse_scout_repos — array, default [] (read by Reuse Scout)
• cost_breaker_baseline_usd_per_day — number, default 50.00
• cost_breaker_band_pct — number, default 20
• charlie_mode — enum, default full (see F13)

New keys can be added freely as needs surface — no ADR requirement (this is an internal tool, not a customer ADO surface). Adds are tracked in this roadmap page.

Bootstrap validator

JSON-schema validates L1+L2. Fails loud at bootstrap on any missing required L2 key. No "happily start with missing config and discover the gap mid-Friday-sweep."

Config fingerprint

Peers stash a hash of all observed config values in their boot ack. Steward diffs fingerprints across roles at each scout-sweep. Mid-flight drift surfaces as a class='audit' row.

F7 engagement_id on portfolio-shareable tables only

Add engagement_id to tables that participate in cross-engagement queries. Do not add to engagement-active body tables — those are partitioned by schema.

Where it goes

YES: rollups, ratified ADR metadata, reuse_candidates, peer_metrics, cost_telemetry, every v_portfolio_* view.
NO: signals, agent_runs, decisions, comms_drafts, briefs. These are scoped by being inside a schema; engagement_id is implicit.

Plumbing

Default-via-session-var (peer's connection sets SET haleon.engagement_id = 'haleon' at session start; SP DEFAULT reads from the var). Built into the migration target schema in F1, not retrofitted afterwards.

F8 Agent governance suite (model pin + canary + brief versions + append-only)

One shipped suite covering four governance gaps: model drift, prompt regression, brief versioning, and DB-level append-only enforcement.

(a) Model pin + drift alert

Model id (claude-opus-4.7-1m-internal) explicitly pinned in workflow.json per role. Steward emits an audit row if the spawn-returned model identity drifts from the pin.

(b) Canary regression corpus

Per-role canned scenarios (5–10 each), authored jointly by SA + CoS. Steward runs them weekly. Output diffed against pinned baseline; deviation above threshold opens a class='audit' row.

(c) Brief versioning

New peer_brief_versions table mirroring the existing skill_versions pattern. Brief edits write a version row. No more silent brief edits.

(d) DB-level append-only enforcement

Revoke UPDATE/DELETE on agent_runs base-table to all roles including anonymous; SP-mediated writes are the only survivors. Safe to ship now (already SP-only-write). Sequenced: applying the same pattern to the 6 ISS-22-residual tables (Brief / MeetingPrep / PdSyncPrep / QuietWatchState / Signal / SteercoPrep) requires INSTEAD OF UPDATE shims first — that's a follow-up bundle.

Shipped 2026-06-01 (Wave 2). F8(a) model pin: grep "model" loom/workflow.json haleon/workflow.json returned 6 hits of claude-opus-4.7-1m-internal across all peer-ring roles. F8(a) drift audit-emit: skill ~/.copilot/m-skills/model-pin-drift/ present (check_model_pins.py + SKILL.md); forced-drift produced agent_runs row id=ed668258-72f3-497a-ad21-ae68bbcf308e with triggered_by=model_pin_drift:role=Steward;pinned=claude-opus-4.7-1m-internal;actual=claude-opus-4.6; post-test grep confirmed all 3 peer pins restored to claude-opus-4.7-1m-internal (lines 11/19/27 of haleon/workflow.json). F8(b) canary corpus: 9 scenario files at ~/.copilot/m-skills/canary-corpus/scenarios/ (3 per role); runner executed steward-01-agent-runs-spine end-to-end (exit code 0, VERDICT=PASS), wrote baseline artifact ~/.copilot/m-skills/canary-corpus/scenarios/baselines/steward-01-agent-runs-spine.baseline.txt (sha256 6b078bbe2f7e92f10936894e9a6af31536b610e22ea94795948ccf7e7c6a264d), and emitted audit row id=c71c311a-ad07-406c-8a09-e364b95118fd with triggered_by JSON {"scenario_id":"steward-01-agent-runs-spine","verdict":"PASS","diff_pct":0,"baseline_created":true}. F8(c) brief versions: SELECT id, brief_name, content_sha256 FROM haleon.peer_brief_versions WHERE brief_name='STEWARD.md' returned row id=2fab20a7-df18-4732-bc8b-2e66fe35db75. F8(d) append-only: UPDATE haleon.agent_runs as haleon_aiac_owner returned permission denied for table agent_runs; sp_create_agent_run(...) in same session returned new row id=a5d5596a-5721-4626-8d42-c6f36174c1b3. Wave 1 F3 chain-repair back-ported to m-skills/mobilise-engagement/ddl-replay/03-f3-hashchain.sql.tmpl at lines 64, 154, 176, 271.

F9 M365 Approvals as canonical sign-off channel

Dead. Feasibility test under Charlie's delegated session (31 May 07:48 BST) confirmed the required scope ApprovalSolution.ReadWrite on the beta endpoint POST https://graph.microsoft.com/beta/solutions/approval/approvalItems is not user-consentable in his tenant — the consent screen returned "Microsoft Graph Command Line Tools needs permission to access resources in your organisation that only an admin can grant". Application permissions are "Not supported" on the endpoint (delegated-only), so a service-principal workaround is also impossible. Admin consent is unobtainable in this engagement.

Fallback (already in production): sign-off ceremony continues over Steward-DM-to-Charlie via m365_send_chat_message, which is the already-working path through Charlie's delegated Teams session. The three gates (comms_drafts.status=awaiting_signoff, ADO writeback pending_approval → queued, scout enable-flag flips) remain on this channel. No new feature needed; the status quo is cemented. Sign-off latency depends on Charlie noticing the DM (laptop-awake, attention-available) — accepted per the no-deputy + no-timeout posture.

Corrections to prior framing: the scope was previously written as "Approvals.ReadWrite" — the actual scope name is ApprovalSolution.ReadWrite. The endpoint is beta-only, not v1.0.

F10a Reuse-candidate drain-and-store (Curator stage 1)

Stops Reuse Scout's outputs from fading. Single-engagement, lives in the engagement schema. Buys time before the cross-engagement Library Curator (F10b) is ready.

What gets built

• reuse_candidates table in the engagement schema with columns: id, seen_at, actioned (bool), actioned_at, dismissed (bool), dismiss_reason (text), plus signal back-references.
• Reuse Scout signals drain into reuse_candidates on first triage.
• CoS surfaces them in daily brief / triage skill (CLI for now; dashboard later via F14).

Shipped 2026-06-01 (Wave 3). Table: SELECT column_name FROM information_schema.columns WHERE table_schema='haleon' AND table_name='reuse_candidates' returned 9 columns (id uuid PK, seen_at timestamptz, signal_id uuid FK→haleon.signals(id) ON DELETE SET NULL, signal_summary text NOT NULL, actioned bool default false, actioned_at timestamptz, dismissed bool default false, dismiss_reason text, portfolio_shareable bool default false); partial indexes idx_rc_unactioned (WHERE NOT actioned AND NOT dismissed) and idx_rc_portfolio (WHERE portfolio_shareable) both present. Drain: function haleon.sp_drain_reuse_candidates() created (SELECT proname FROM pg_proc WHERE proname='sp_drain_reuse_candidates' returned 1 row); end-to-end probe planted signal id=49f217b2-9a46-44cf-9f17-1efba0ba9919 with source='reuse-scout', drain returned 1 row inserted, candidate id=d080da55-436d-4130-ad1d-c638fcaaa2fe visible with signal_summary='WAVE3-TEST: foo bar reusable pattern'; cleanup confirmed 0 rows remaining. Drain uses COALESCE(s.subject, s.body_excerpt, 'untitled') (live haleon.signals has no title/summary columns — only subject and body_excerpt). CoS hook: ~/.copilot/m-skills/daily-brief/SKILL.md updated — new "Reuse candidates awaiting triage" section sourced from SELECT id, seen_at, signal_summary FROM haleon.reuse_candidates WHERE NOT actioned AND NOT dismissed ORDER BY seen_at DESC LIMIT 10.

F10b Library Curator MVP (Curator stage 2)

F11 Engagement-onboard skill (mobilise-engagement)

The operational means that turns "multi-engagement capability" into "Day-0 takes hours, not weeks." Without this, the factory claim is aspirational.

Live-proven 31 May 2026: test-engagement-1 mobilised end-to-end and the per-engagement DAB MCP (test-engagement-1-aiac-db) verified by an out-of-process read_records against the seeded ScoutEnableFlags row.

What the skill does (in order)

1. Takes an engagement-pack manifest as input.
2. Validates it against the L2 JSON schema (from F6).
3. Provisions a new schema in the shared Flexible Server with schema-scoped roles + replicated sp_* / *In shims.
4. Provisions Key Vault secret entries (engagement-prefixed naming per F4).
5. Registers MCP identities (azure_devops, msx-mcp, github, M365 mailbox).
6. Bootstraps peers via existing bootstrap-roles.
7. Runs first prove-cycle (3-greens-equivalent smoke test).
8. Returns ready/not-ready with structured failure reasons.

Rollback semantics

Smoke-test fail at any step rolls back the schema-create transaction; Key Vault entries are left (idempotent re-run) but flagged for manual review. No partial-onboard state in production.

Invocation authority

Charlie-only (locked 31 May 2026). The skill is destructive (provisions a new schema, registers MCP identities, may consume budget headroom). CoS cannot self-invoke; the trigger is always a Charlie command in the Operator session.

Step 5 gotcha — dab-config.json needs runtime.mcp

The per-engagement dab-config.json materialised in Step 5 MUST include a runtime.mcp block with enabled: true AND an explicit dml-tools map. Without it, DAB starts cleanly, the MCP server registers in Clawpilot's UI, every tool checkbox shows "enabled", and the host still rejects every call with ToolDisabled / "The <tool> tool is disabled in the configuration." — the rejection string is emitted by DAB itself, not by Clawpilot's tool registry. Observed against test-engagement-1 (31 May 2026); reference shape is the haleon dab-config.json. Captured in m-skills/mobilise-engagement/SKILL.md.

F12 Per-engagement cost attribution + per-engagement-OR-portfolio breakers

Real financial control once there's >1 engagement. One engagement can't consume another's budget; portfolio ceiling sits above the sum.

Wave-1 SHIPPED 2026-06-01: F12 SQL applied to live haleon (lab sub `ME-MngEnvMCAP180885-smccormick-1`); verified by 5 probes — `cos_config` seeded (3 cost-breaker keys present), `sp_check_cost_breaker` arity=4 (accepts `p_engagement_id`), `agent_runs_class_check` IN-list contains `breaker_trip`, `cost_telemetry_period_agent_engagement_key` UNIQUE constraint present, `sp_verify_chain()` returns OK post-chain-repair (74 rows verified).

What gets built

• cost_telemetry gets engagement_id (lands in portfolio-shareable territory per F7).
• Existing sp_check_cost_breaker + sp_check_cost_breaker_rolling extended: compute per-engagement spend AND portfolio-total. Either tripping disables scouts for the relevant scope.
• Per-engagement baseline default $50/day per engagement (locked 31 May 2026 — "fine to start, tune by observation"), configurable via cos_config.cost_breaker_baseline_usd_per_day.
• Portfolio ceiling default: sum-of-per-engagement-caps + 20% headroom.
• Daily attribution rollup feeds F14 and F17 dashboards.

F13 Charlie mode (load-shedding) — no deputy

A typed availability state Charlie sets in cos_config, honoured by every outbound path. Per Charlie's ruling: no deputy, no auto-escalation — Charlie absorbs the latency consequences.

Wave-1 SHIPPED 2026-06-01: F13 SQL applied to live haleon; verified by 4 probes — `charlie_mode` key present with value `"full"`, `sp_set_cos_config` paired-row emission tested live (`mode_flip:from=full;set_by=wave-1-steward;to=quiet` row observed, then reset), `agent_runs_class_check` IN-list contains `mode_flip`, `comms_drafts.compliance_override` column present as `boolean`.

What gets built

• cos_config.charlie_mode enum: full | quiet | emergency | silent.
• Outbound-voice, daily-brief, ring-tick (always emits — internal infrastructure), scout-sweep, and the m365_send_chat_message Steward-DM sign-off path (the production sign-off channel post-31 May F9 retirement) all honour the mode. outbound-voice uses defer-to-queue semantics (drafts still written to comms_drafts; Steward-DM solicitation suppressed in non-full modes); briefs + scout-sweep suppress under emergency + silent.
• silent mode mutes all outbound except compliance-flag signals (the emergency-override scope — signals tagged with a compliance-regime routing tag punch through via a compliance_override = true flag on the comms_drafts row, firing Steward-DM regardless of mode).
• Calendar-driven mode-set as a v2 extension.

Honest trade-off

With no deputy and no Approvals-channel timeout (F9 retired), an extended Charlie absence under silent means the Steward-DM sign-off queue (comms_drafts + ado_writeback_queue rows at status = pending_approval) grows indefinitely — the system does not auto-approve, does not escalate, does not drain. silent mode damps inbound volume but doesn't drain backlog; Charlie returns to a batch-review queue proportional to absence duration. This is the explicit locked ruling ("Charlie absorbs the latency consequences").

F14 Engagement-internal observability dashboard (Power BI)

Turns the audit spine from "evidence in a DB" into "system health at a glance." Single engagement; cross-engagement view is F17.

Shipped 2026-06-01 (Wave 5 follow-up): F14 dashboard published in PBI workspace m-tester-obs (5fe04c44-2297-4089-8747-069618335e66, MSIT tenant) by operator. Automated f14-publish skill is wired and live-tested (audit 47d31b5e-cf45-404b-874a-98e2bcd1efa7); apply-path gated on operator-provisioned Entra SP credentials in KV slot pbi_reader_conn. SP provisioning is blocked on Service Tree ID — residual carried to W6+.

Wave-5 substrate + skill SHIPPED 2026-06-01 (tag remains pending-testing pending operator residuals): f14-publish skill apply-path wired and live-tested (audit 47d31b5e-cf45-404b-874a-98e2bcd1efa7); gates working; correctly blocked on operator-side residuals — manual MSIT Power BI service-principal provisioning + .pbix build. Per CoS classification: kernel D1 operator-only, NOT a W5 substrate gap. Re-flip to shipped on operator-residual close.

What gets built

• Power BI semantic model over the engagement schema (read-only, hourly refresh).
• Tiles: rotation cadence, run-rate per role, cost burndown vs baseline, scout sweep success rate, open-run gauge (HS-2), Approvals queue latency, sign-off queue depth.
• Published to a Microsoft-internal Power BI workspace.
• Designed for escalation-by-exception: drill-in only when a tile reds.

F16 Risk register — extend existing RIB schema

The 5-3-2-1 brief surfaces 5 risks per slot but they're consumed-and-discarded today. This gives them a continuing register. Extends existing risks_issues_blockers (RIB) rather than creating a new table (avoids load-bearing-decision-#5 violation).

Schema additions to RIB

• class enum: delivery | engagement. Both go in one table, distinguished by class.
• decay_at — auto-decay default: 30 days from last evidence touch.
• escalation_threshold — severity at which a risk auto-surfaces in the brief.
• engagement_id — per F7, since risk register IS portfolio-shareable.

Severity / likelihood scale (recommended)

1–5 numeric for both severity and likelihood. Combined risk score = severity × likelihood (1–25).

Workflow integration

• Daily-brief 5-3-2-1 surfaces from RIB (not from CoS's recall).
• Phase-boundary ceremony burns it down (resolves or re-evaluates each open risk).
• Engagement-closeout (F15) archives open risks into the transition pack.
• SA owns delivery-class risks; Steward owns engagement-class risks; CoS authors first draft on signal-extraction.

Shipped 2026-06-01 (Wave 2). RIB extended via ALTER TABLE haleon.risks_issues_blockers: information_schema.columns probe returned all 7 expected columns — class (USER-DEFINED haleon.rib_class enum), decay_at (timestamptz), escalation_threshold (int), engagement_id (text, pre-existing from F7-precursor), severity (int), likelihood (int), risk_score (int GENERATED). Test row (severity=4, likelihood=3, class=delivery) returned id=1181cf11-15c1-43f4-b6ab-9a058750dcc4 with computed risk_score=12, decay_at=2026-07-01 00:57:36+01:00 (~30d out), escalation_threshold=4. Migration preserved 2 existing rows (severity enum→int mapping low=1, medium=2, high=3, critical=4); recreated dependent views v_open_rib_by_pod and v_rib_in post-CASCADE; dropped orphan haleon.rib_severity type after pg_depend confirmed zero remaining references.

F18 Per-scout proven flags (per-scout, not shared)

Closes Charlie open question #2. Per-scout granularity gives each K-scout its own supervised prove path with per-flip audit attribution.

What gets built

• ALTER scout_enable_flags adds: backlog_sentinel_proven, pipeline_watcher_proven, reuse_scout_proven, intake_triage_proven.
• Existing scout_proven remains for Signal Scout only.
• Per-scout flip ceremony documented per scout brief.
• sp_check_scout_enabled() updated to require the per-scout flag for K-scouts.

Recommended ordering

First scout to prove: Backlog Sentinel (lowest privacy risk; ADO is already a primary engagement surface).

F20 MCP restart-resilience drill + runbook

Confidence under daemon churn. Today the documented behaviour assumes leases release cleanly and watermarks hold under a DAB restart. This exercises it. (Exercises the Clawpilot-resident MCPs — no Azure-hosted MCPs exist in this posture.)

Wave-1 SHIPPED 2026-06-01: F20 destructive drill executed against live haleon DAB (`drill_id=drill-20260531-f39a2027`); 5 DAB processes killed mid-lease via SIGKILL, restarted PID 6556. All 4 invariants PASSED: (4a) `scout_lease` reclaimed by TTL expiry at 300s, (4b) `signal-scout` watermark un-advanced from W₀=`2026-05-30 11:40:00+01:00`, (4c) no unexpected partial `agent_runs` rows, (4d) `sp_create_signal` ON CONFLICT dedup intact (signals count stable at 18). Summary audit row `5338349e-ee57-4752-b643-8cfac978a4d9` written with `triggered_by=mcp-restart-drill:check=summary;result=pass;detail=4_of_4_passed;drill_id=drill-20260531-f39a2027`.

Drill procedure

1. Start a scout-sweep manually.
2. Mid-sweep, kill DAB (or its containing process).
3. Restart DAB.
4. Verify: scout_lease released by TTL expiry; watermark un-advanced (next sweep resumes); no partial agent_runs rows; idempotency on re-run holds (ON CONFLICT dedup works).
5. Document any deviation as a Steward audit row.

Cadence

Quarterly + post any DAB version bump.

F22 Always-on scout tier (Container Apps Jobs)

Dead. The scouts read M365 / ADO / MSX Dataverse / GitHub through MCPs that run under Charlie's user-delegated identity. Lifting them to Container Apps Jobs would require Charlie's tenant to grant equivalent application permissions (Microsoft Graph application scopes, ADO service-principal access, MSX Dataverse service identity, GitHub App). Per the 31 May ruling, this is not available. There is no substitute available without Charlie's tenant identity.

Successor: see F26 — Clawpilot-resident always-on session that ticks scouts on its own internal cron while the laptop is awake. Combined with the watermark/cursor logic each scout already has, laptop-asleep gaps cause latency, not data loss.

F26 Clawpilot-resident always-on session pattern (F22 successor)

A long-lived Clawpilot session whose only job is to tick the scout-sweep + core-tick + drainer + daily-brief crons on its own internal schedule, for as long as the laptop is awake. Honest about the laptop-asleep gap: it doesn't disappear, but the watermark/cursor logic each scout already has means sleep gaps cause latency, not data loss.

Wave-1 SHIPPED 2026-06-01: Ticker spawned via `m_spawn_session` (sessionId `3f135ccb-7401-4f45-858c-1a9828582abe`, Haiku 4.5, `tier_4_orchestrator`); ack`"Ticker online — entering cron loop."` returned. After one-shot sessionId wire-up (closes an HS-1 bootstrapping gap in the spawn ceremony — logged as Wave-2 follow-up), first core-tick observed at `2026-06-01 00:25:52` (`agent_runs.id=665cce6a…`, `class=audit`, `triggered_by=ticker_tick:cadence=core;result=pending`). Post-Ticker `sp_verify_chain()` returns `status=OK, rows_checked=76, tail=665cce6a…` — confirms the chain-repair `clock_timestamp()` fix holds under live multi-writer.

What gets built

• A new long-lived Clawpilot session (separate from CoS/SA/Steward) called Ticker (locked 31 May 2026) — tier_4_orchestrator, spawned at Clawpilot startup by the Operator session.
• Internal cron loop: core-tick every 15 min, scout-sweep every 2 h, daily-brief at 07:00 + 17:00, drainer-tick every 15 min. All running INSIDE Clawpilot, using existing MCPs and existing peer-ring tools.
• Watermark/cursor logic on every scout (largely already there) so a sleep gap causes resume-from-cursor, not data-loss.
• Steward audit row per tick (existing pattern).
• Steward observability: if Ticker hasn't ticked in N minutes during a session, flag.

Acceptance decision (Charlie 2026-05-31)

Laptop-awake-only sweep cadence — accepted. Sleep gaps are absorbed (watermarks ensure latency, not data loss). No second always-on workstation.

Ticker session shape

New long-lived session, tier_4_orchestrator (ratified by Charlie 2026-05-31; workflow.schema.json is the source of truth for the tier registry — STEWARD.md updated to match). Model: claude-haiku-4.5 (mechanical orchestration, not cognitive work) — ratified 2026-05-31. Spawned by the Operator after bootstrap-roles completes (Option B — separate from peer-ring bootstrap, not part of bootstrap-roles itself, not in workflow.json) — ratified 2026-05-31. Not a peer-ring participant; not rotated by Steward; restarted on each Clawpilot startup. Spawn ceremony at m-skills/ticker/SKILL.md; idempotency via m_list_active_sessions filter + tick_lease CAS backstop.

Cron loop mechanism

PowerShell 60-second sleep timer with cadence-due checks on each wake. Core-tick every 15 min, scout-sweep every 2 h, daily-brief at 07:00 + 17:00, secret-scan + kernel-purity-scan daily at 06:00 UTC. Ticker invokes existing ring-tick skill (Jobs A + B) and daily-brief — does not reimplement cadence logic. Drainer-tick runs inside core-tick (ring-tick Job A step 4); Ticker emits a separate cadence=drain audit row for observability.

Observability

Every tick emits an agent_runs row: class=’audit’, triggered_by=’ticker_tick:cadence=<core|sweep|brief|drain|scan>;result=<ok|skip|fail>’, two-phase lifecycle. Steward gap detector: 30-minute threshold on cadence=core rows; flags a single ticker_gap:gap_minutes=<N> audit row per gap event (deduplicated). Sleep gaps are expected and produce ticker_gap audit rows but no data loss — all five scouts (Signal Scout, Backlog Sentinel, Pipeline Watcher, Reuse Scout, Intake Triage) resume from their ScoutWatermarkIn cursor on wake.

F27 Laptop-continuity playbook (re-install + re-auth + resume)

Documents the laptop-loss recovery procedure honestly. The hosted PG (F1) survives; the cognitive layer and every MCP identity is laptop-resident and must be rebuilt. This is a runbook, not infrastructure.

Wave-1 SHIPPED 2026-06-01 — live infrastructure verified: Storage account `stclawpilotcorpusuks` provisioned in `rg-clawpilot-uks` (UK South, Standard_ZRS, StorageV2, `--allow-blob-public-access false`, TLS 1.2, blob+container soft-delete 14d, versioning enabled, 3 containers `briefs`/`skills`/`docs`) — verified by `az storage account show` + `az storage container list` (Entra-auth, no SAS). SWA `swa-peerring-docs-uks` provisioned (Free, West Europe) at `https://orange-plant-0b5323e03.7.azurestaticapps.net` — verified by `GET /roadmap.html` returning HTTP 200 with "Force-multipliers" + 21 F26 references. `corpus-sync` skill built locally (3 files: `SKILL.md` 182L, `sync.ps1` 519L, `bootstrap-stub.ps1` 59L); uploaded to `stclawpilotcorpusuks/skills/corpus-sync/` (authed download byte-identical, anonymous `irm` returns 409 PublicAccessNotPermitted confirming RBAC enforcement). Bootstrap stub also published to SWA anonymous URL `https://orange-plant-0b5323e03.7.azurestaticapps.net/skills/corpus-sync/bootstrap-stub.ps1` (`irm` returns byte-identical script unauthenticated) — SA review condition met by `sync.ps1` push-mode atomically re-publishing stub to SWA on drift. KV `kv-clawpilot-uks` provisioned (RBAC-auth, purge-protection 90d); secret `m-encryption-key-enc-backup` written from `~/.copilot/m-encryption-key.enc` (75B) — byte-compare round-trip verified True. OneDrive `clawpilot-recovery.md` mirror DROPPED per §G #2a optionality (AADSTS65002: Azure CLI lacks `Files.ReadWrite` consent in active tenant; recovery card content already baked into `bootstrap-stub.ps1` — no unique survival value lost). MCP restart drill (F20) PASS 4-of-4 invariants; Ticker (F26) first core-tick observed in live `agent_runs`. F3 hash-chain BROKEN finding triaged via SA push-back (rejected verify-only band-aid): root-cause fix applied as 3 SP changes (`sp_create_agent_run` swap `now()`→`clock_timestamp()` and prev-lookup `DESC,DESC`→`DESC,ASC`, `sp_verify_chain` ordering `ASC,ASC`→`ASC,DESC`) + index `ix_agent_runs_chain_order (spawned_at ASC, id DESC)` + data-repair recomputing 7 divergent rows under advisory lock; in-tx `sp_verify_chain()` returned OK before COMMIT; post-Ticker chain verify OK at 76 rows. Decisions row `95a49dec-dc5a-425c-b175-3a4bf1e08e83` (tag `chain_repair`).

Playbook contents

1. Acquire replacement laptop.
2. Install Clawpilot.
3. Re-authenticate every MCP interactively under Charlie's identity: M365 builtin, ADO MCP, MSX MCP, GitHub MCP, filesystem MCP, playwright, haleon-aiac-db MCP (now pointing at hosted PG via KV-resolved conn string).
4. Validate: each MCP responds to a smoke test.
5. Re-spawn peer-ring via bootstrap-roles haleon. Peers reattach to existing engagement schema; audit spine resumes from last committed row.
6. Validate: peers produce a successful first-tick (CoS reads recent signals, SA reads open ADRs, Steward emits an audit row).
7. Resume scout cadence via F26 Ticker.

Estimated recovery window

Half-day to one day if MCP re-auths are all interactive and there are no admin-consent surprises. Note (Charlie 2026-05-31): the previously proposed quarterly wipe-drill dry-run on a spare device or VM is retired — Charlie cannot test laptop wipes in his environment. The playbook is now exercised organically only if/when a real recovery is needed.

Two tracks

• Track 1 — same laptop, fresh session (“where was I?”): Clawpilot restarted but disk intact. Check active sessions, re-bootstrap if peers died, read latest plan.md, resume. ~15 min.
• Track 2 — new laptop, cold start: Full Step 1–7 recovery. Re-auth in canonical order (Entra → GitHub → WorkIQ/M365 → MCPs → DAB → bootstrap-roles → Ticker). Half-day to one day.

Source-of-truth in Azure storage

The cognitive corpus (role briefs, skills, docs, workflow configs) syncs to a single Azure Storage account (stclawpilotcorpusuks, ZRS, UK South, Entra RBAC only, no SAS tokens) via the corpus-sync skill. Three containers: briefs, skills, docs. Blob versioning with 14-day soft-delete retention provides point-in-time rollback. Conflict semantics: ETag/If-Match on every PUT; 412 → skip + warn (never auto-overwrite). Corp-net reachability for the blob endpoint should still be empirically tested before provisioning — it has never been verified either way on Charlie's network. (The earlier "by analogy to the Loop Fluid relay block" framing has been retracted; that block was a one-day issue on a different network, not a property of Charlie's corp environment.) Internal docs hosted via Azure Static Web Apps; auth scope open — anonymous public docs vs Microsoft-tenant-only Entra auth, Charlie to pick before docs hosting is provisioned. Per SA-ADR-F27-STORE and SA-ADR-F27-DOCS, both ratified 2026-05-31 (DOCS ratified with auth-scope question still open).

Sync-as-a-skill with bootstrap stub

The sync mechanism is itself a Clawpilot skill (corpus-sync) with a ~50-line bootstrap stub. On a bare laptop, the stub is fetched from a hard-coded blob URL (https://stclawpilotcorpusuks.blob.core.windows.net/skills/corpus-sync/bootstrap-stub.ps1), authenticates via Entra, pulls the full skill manifest, and invokes corpus-sync pull to restore the entire corpus. Push-on-edit propagates changes to blob storage with ETag conflict detection. Post-F26, Ticker runs corpus-sync push daily at 23:00 UTC as a drainer job (ratified 2026-05-31, gated on F29 + storage being live).

Bootstrap-stub URL survival channel (Charlie ruling, 2026-05-31)

A1 (hard-coded blob URL stub) PRIMARY + A2 (bundled in Clawpilot installer) FALLBACK — both accepted. The URL itself, plus the broader “where everything lives” inventory, lives on a dedicated Loop notebook continuity page (“if you lose your laptop, start here”) on the engagement's Loop notebook — Entra-authenticated, server-side, reachable from phone / web / second laptop, and reachable on Charlie's corp net. (The earlier "corp-net blocks Loop Fluid sync" assumption was wrong — that block was a one-day issue on a different network, not a property of Charlie's corp environment. Tether/mobile-data workaround retracted.) The Loop continuity page is the primary survival channel. An optional OneDrive clawpilot-recovery.md mirror under Charlie's UPN may be maintained as defence-in-depth duplicate — Charlie may keep it or not; it is no longer required as a Fluid-block workaround. Wave-1 build (31 May 2026): attempted in the lab sub ME-MngEnvMCAP180885-smccormick-1 and dropped per §G #2a optionality; the Azure CLI first-party app has no Files.ReadWrite consent against the active tenant (AADSTS65002 risk realised; managed-environment admin UPN, not Charlie's smccormick@microsoft.com identity); the recovery-card content is already baked into corpus-sync/bootstrap-stub.ps1 + SKILL.md (Item 6 verified), so the OneDrive duplicate adds no unique survival value beyond the F29-deferred Loop continuity page. Loop continuity page is a deliverable artefact (deferred 2026-05-31 to F29) — page name, content sections, and maintainer pending under the F29 wiring work.

Acceptance decision (Charlie 2026-05-31)

During the recovery window, signal collection halts entirely (no scouts, no audit writes, no briefs) — accepted. No parallel always-on instance on a second device.

F29 Generic Loop publisher skill + per-engagement Loop wiring

Shipped 2026-06-01 (Wave 4, Round 5c-4) — live-proven against Charlie's real Haleon Loop notebook with round-trip verification + idempotency proof. Pack-schema extension: m-skills/_schemas/pack.schema.json extended with the F29 5-key set — loop_notebook_url, loop_front_page_url, loop_continuity_page_url, loop_status_page_url, loop_pages (map) — all optional, sentinel-pattern ^(https://[^\s]+|pending:[a-z0-9-]+)$ to admit a pending:charlie-input placeholder. Bootstrap brief's loop_notebook_section_id minimal-pair key dropped per SA reconciliation (not in F29). $schemaVersion held at 2 (additive, all-optional — backward-compat). Validator (jsonschema Draft7): haleon/pack.json PASS pre-flip; post-flip with loop_notebook_url: pending:charlie-input PASS; negative control ftp://… FAIL. Engagement-pack patch: m-engagement-packs/haleon/pack.json += loop_notebook_url: pending:charlie-input; awaits Charlie's real per-engagement Loop URL (front + continuity + status + archive map optional). IA templates: m-skills/loop-publish/templates/overview-template.md (5672 B, weekly-review cadence) + daily-template.md (8573 B, strict order: pulse → 5-3-2-1 brief → top-5 risks → recent ADRs → links → archive). Six DB queries spec'd against live haleon entities (CustomerHealth, Brief, RiskIssueBlocker, Adr, Decision filtered decision_class='use_case'); template column-set re-verified against live DAB read 2026-06-01 (customer_health uses narrative/period_end/computed_at/sentiment_*, not the earlier-drafted state/as_of_date). Skill artefacts: m-skills/loop-publish/{SKILL.md (107 L), loop-publish.ps1 (440 L), config.json.example}; CLI shape --engagement <name> --section <id> --content-source <brief|adrs|risks|status|links|full> [-WhatIf]; render via {{key}} substitution (no Jinja2 dependency); drift-gate via sha256 of normalised body vs decisions tagged loop_publish_state (per (engagement, content-source, page-url) tuple); audit via direct SELECT haleon.sp_create_agent_run(…) with session_turn_seq auto-allocated by sp_next_session_turn_seq. End-to-end dry-runs against live haleon DB (Playwright path intentionally not invoked — no PROD/TEST Loop URL yet): all 6 content-sources rendered + audited — brief (dd1f17ef-f551…) 1603 chars; adrs (efa37c7d-92c0…) 71 chars graceful-empty; risks (1de27354-5407…) 410 chars 2-row table; status (99640788-c630…) 217 chars derived-green; links (1bd81530-2d9c…) 369 chars + re-run idempotency proof (ddcad7c8…); full (089492cc-1826…) 314 chars. Real haleon-pack gate-proof: blocked: loop_notebook_url is pending:charlie-input + audit (183a1980-f465…) — honest design-pending-apply state, non-zero exit. Consumer hooks (W4-4): m-role-briefs/CHIEFOFSTAFF.md += brief-write → loop-publish --content-source brief handoff (after sp_upsert_brief close-out); SOLUTIONARCHITECT.md += ratify → --content-source adrs on successful sp_advance_adr_stage(…'ratified'); STEWARD.md += --content-source status on scout-sweep/health-tick close + after class='audit' writes whose triggered_by starts with kernel-purity-scan: / gap: / open:; LIBRARY-CURATOR.md += --content-source links at end of each scan turn. All four briefs carry the pending:-skip rule + drift-gated double-invocation safety note. Live publish probe 2026-06-01 — Fluid Framework sync fail confirmed: haleon pack.json:loop_notebook_url backfilled with Charlie's real Haleon Loop notebook URL (validator PASS against extended schema). End-to-end Playwright probe under Charlie's identity: navigated to workspace OK (sidebar loads, existing Status system page renders), new-page creation routed to a fresh page id (d69b3a6b-8f00-4813-9623-41ac901dce8e), but Fluid Framework content sync FAILED immediately with the dual symptom Charlie himself observed on 2026-05-29 (Brief Insight #5): persistent banner "Sorry, we couldn't save your work" + console error "Unattached workspace is not tracked by workspace tracker". URL prefix decodes to sharepoint-df.com (SharePoint Dogfooding tenant — likely the relay-reachability root cause from corp network/auth context). Failure is session-wide (persists across workspace switch to Tester Notebook), not Haleon-specific. Evidence: scratchpad/loop-fluid-sync-fail-1.png + loop-fluid-sync-fail-2-tester-notebook.png. Audit row e9832d0c-e291-402e-ac78-a69c41e7ac12 with triggered_by shape per F29 spec (result=fluid_sync_fail). Material implication: the 2026-05-31 retraction of the Fluid-reachability worry was premature; F29's "graceful Fluid-sync error handling (defensive engineering, not Charlie-specific)" turns out to be the primary mode, not a defensive edge case. The loop-publish skill's audit-emission path already encodes this contract (result=fluid_sync_fail as a documented audit verdict) — the still-TODO Playwright wiring needs the detection logic for this failure shape (banner text + console substring + relay WebSocket fail) baked in BEFORE first happy-path publish is achievable. Live publish proof 2026-06-01 (Round 5c-4) — round-trip verified, idempotency proven, F29 SHIPPED: Charlie supplied the canonical Haleon `/ws/` workspace URL plus pre-decoded loop_workspace_drive_id (b!o26ka_B3LEKYc2UHaB1H-49Q45g7fgtLjfqcCQGCwJdRKwQdXY-qQolwRJ9pnARj) + loop_workspace_item_id (01J62HDHFL4DXI24KPHNDJS47GH7IWHIC2); all three backfilled into haleon/pack.json (validator PASS against tightened R5c-2 schema). End-to-end Playwright publish probe under Charlie's identity (Edge persistent context): navigated to the `/ws/` URL cleanly — no "Oops!" modal, no "Unattached workspace" console error, no save-failure banner (every R5c session-poisoning guard signal NEGATIVE). R5c-6 orphan cleanup pass: enumerated the Haleon workspace page tree, deleted three orphan "Untitled" pages from the 5b broken runs (audit rows 36d277ce-aa18-4e2b-985d-e625ac60bce9 + 36fda644-b5de-480c-badd-e114a7cf5c1b + 53fd036e-d06e-415d-89c0-539bf2fb7b1f; the 3rd was likely the d69b3a6b-8f00-4813-9623-41ac901dce8e page-id from the broken 5b run). Resolve-or-create flow: created a fresh workspace page, IMMEDIATELY set deterministic title "Clawpilot smoke-test — DO NOT EDIT (2026-06-01)" (R5c-6b invariant: no codepath in loop-publish.ps1 can produce an "Untitled" page itself; the deterministic title-set step is what protects against orphan creation if interrupted), typed automated body content via Loop's contenteditable editor, "Connected to Haleon" indicator visible. Round-trip verification (the necessary-but-not-sufficient guard R5c-1 introduced): computed body_sha = 2448bfbd695777eff82103831c7f98bdc253c820d8d94d4c92986eff862e90d3 pre-reload; performed FULL PAGE RELOAD via page.goto (forced re-fetch from storage farm, not local Fluid cache); re-read title + canvas innerText; recomputed readback_sha = 2448bfbd695777eff82103831c7f98bdc253c820d8d94d4c92986eff862e90d3 — EXACT MATCH. First-publish audit row 75fb5af8-3e94-4bfc-8e2e-f2b72d64250e emitted with result=ok;round_trip=verified. Idempotency proof: immediately re-evaluated rendered sha against persisted sha — matched → result=noop, no Loop re-edit performed. Second-publish audit row 0e7b0dc2-8797-43f6-b80c-9c65a1681d9f emitted with result=noop;idempotent=true;no_re_edit=true;prior_run_audit=75fb5af8-3e94-4bfc-8e2e-f2b72d64250e. Screenshots: scratchpad/loop-publish-r5c4-prereload.png + scratchpad/loop-publish-r5c4-postreload-VERIFIED.png (both show the smoke-test page rendered cleanly in Haleon workspace). F29 is now genuinely shipped: artefact exists in Charlie's real Loop notebook AND the audit chain has tamper-evident proof of round-trip + idempotency. The 5b retracted diagnosis (Fluid sync fail) and the 5c correction (dead-page session-poisoning) are preserved above as chain-of-custody for the audit trail; the R5c-1 hardened result-classification (dead_target_page / poisoned_session verdicts + R5c-6 orphan cleanup pass + deterministic-title invariant) means the next run won't reproduce either symptom even if Charlie deletes the smoke-test page out-of-band.

Turns Charlie's Microsoft Loop notebook into a first-class engagement surface: a project front page that receives ongoing status updates, a dedicated continuity page that carries the F27 bootstrap URL + “where everything lives” inventory, and any other notebook pages an engagement chooses to wire in. Generic by design — the mechanism is kernel, the targets are per-engagement.

Why

Charlie's working pattern uses a per-engagement Loop notebook with multiple pages (front page, docs links, database links, key resources, recurring meetings). Status updates and continuity information naturally belong there — Loop is Entra-authenticated, server-side, laptop-independent, reachable from phone / web / second laptop. Hard-coding any Loop URL into a kernel skill would be worse than useless because the framework runs against multiple engagements; each must point at its own notebook.

What gets built

• Kernel skill loop-publisher: generic. Inputs: target page URL + content payload. Uses the existing /loop Playwright skill under the hood (or extends it). Knows nothing about any engagement.
• Engagement-pack schema extension (L2 per F6): pack.json gains new optional keys — loop_notebook_url, loop_front_page_url, loop_continuity_page_url, loop_status_page_url, and an open-ended loop_pages map for engagement-defined extras. SA owns the schema; new engagements supply the URLs at mobilise-engagement time.
• Consumer hooks: daily-brief reads loop_front_page_url from pack, calls loop-publisher to publish/refresh on each brief cadence. F27 continuity content reads loop_continuity_page_url, populates once + refreshes on edits to the continuity inventory. (No periodic refresh cadence — the F27 quarterly wipe-drill cadence was retired 2026-05-31.)
• Graceful Fluid-sync error handling (defensive engineering, not Charlie-specific): loop-publisher detects Loop Fluid Framework sync failures (WebSocket failures to *.fluidrelay.azure.com, the “Sorry, we couldn't save your work” / “Oops! moved or deleted” symptoms) and fails gracefully with a structured warning routed to Charlie via Steward-DM rather than failing silently. Note 2026-05-31: Charlie's corp environment does not block Fluid as previously assumed; this is general engineering hygiene against any Fluid failure mode, not a Charlie-specific mitigation.
• Audit row per publish: class='audit', triggered_by='loop_publish:page=<short-name>;result=<ok|fluid_sync_fail|fail>' — visibility into what got refreshed when.

Onboarding workflow

When a new engagement is mobilised: Charlie (or the operator) creates the engagement's Loop notebook + the standard pages (front, continuity, status), copies their URLs into pack.json, and the peer-ring picks up automatically. No kernel change per new engagement.

Out of scope (deferred)

Loop notebook creation itself — remains a manual one-off per engagement. loop-publisher only writes to pages that already exist.

F28 Approvals-response capture via Graph poll

Dead. F28 was the response-capture half of F9. With F9 retired (consent unobtainable), nothing to poll. Folded back. Sign-off responses arrive via Steward-DM in the existing Teams chat path — CoS reads the reply, applies the CAS state transition through the existing sp_* contracts.

F10c Curator surfacing-to-SA loop (v2)

Closes the find → store → surface → reuse loop. Library Curator surfaces ranked "you've solved this before" hits to SA when SA drafts a new ADR. Defer until pattern_library has enough content to be worth surfacing from.

Wave-6 DESIGN-PENDING-CORPUS 2026-06-01: NOT shipped — surfacing loop deferred until pattern_library holds enough curated rows to surface from. The gating mechanism is live: portfolio.pattern_library_surfacing_gate + sp_eval_surfacing_gate (threshold N=5) are committed and the bidirectional below/above-threshold flip is probe-proven, so F10C auto-fires in W7 the moment pattern_library crosses the threshold. A live gate under a deferred surfacing loop — not a promise.

What gets built

• Embedding-based retrieval over pattern_library.
• SA on new ADR draft: library-search skill returns ranked hits with relevance scores.
• False-positive control: only surface above a confidence threshold.
• Both as an ADR-drafting auto-prompt and as a manual library-search skill.

F15 Engagement lifecycle ceremonies (mobilise / transition / closeout)

Three new Steward-owned ceremonies analogous to existing phase-boundary. Together they form one engagement-lifecycle playbook.

Wave-6 SHIPPED 2026-06-01: The two NEW lifecycle ceremonies (transition-engagement, closeout-engagement) are live-proven in rehearsal against <engagement> — runnable v0.1 skeletons executed end-to-end (transition pack + signed closeout bundle emitted), with CoS content shapes (runbook structure, pod-map, relationship-handoff, lessons-harvest schema, qualification gate) folded into v0.2. Spine refs: transition 21fab3d4, closeout 231e3b40. Caveat: NEW ceremonies only — the historical mobilise-engagement (F11) is untouched.

Three ceremonies

• engagement-mobilise — runs at engagement start. Invokes F11 mobilise-engagement. Writes a structured kickoff artefact (engagement charter, pod map, MCP topology).
• engagement-transition — runs at in-flight architect handover (e.g., Pilot SA → Scale SA). Produces a transition pack: read-only mirror of engagement DB, runbook, ADR index, open-decisions list, active-risks export.
• engagement-closeout — runs at engagement end. Lessons-learned harvest feeds F10b Library Curator. Output is the customer-facing handover bundle (F21).

Bus-factor wiring

Backup-architect MCP identity provisioned via F11. bootstrap-roles can spawn the ring under deputy credentials for transition rehearsals. (Note: no live deputy per Charlie's ruling — this is identity infrastructure, not auto-failover.)

F17 Portfolio read view + cross-engagement dashboard

Cross-schema views and a portfolio Power BI dashboard for Microsoft delivery leadership. Activates when engagement count reaches 2+.

Wave-6 SHIPPED 2026-06-01: Cross-engagement portfolio read-view live-proven against TWO engagements via a registry-driven external aggregator (Option C — no cross-DB FDW: per-engagement readers → local portfolio.* snapshot tables → v_portfolio_* views). Probe confirmed ≥2 engagements with both activity rows genuinely populated. Refs: aggregator run decdfa02, SA seal d8fe0fa4, decisions fc4906e1. Caveat: the view/aggregator tier is what ships (live-proven) — the Power BI workspace publish is design-only / won’t-implement (permanent; not pending-apply, not a W7 build). W7 workaround: the cross-engagement portfolio metrics fold into the 5-3-2-1 brief in the Loop notebook instead of a standalone Power BI dashboard.

What gets built

• v_portfolio_* view set in the portfolio schema, projecting only portfolio-shareable rows + rollups across all engagement schemas.
• Power BI portfolio view: top reuse assets, compliance-regime heatmap, scout health per engagement, cost burn per engagement, ADR ratification rate per engagement.
• Engagement filter + portfolio rollup.
• Published to a Microsoft-internal Power BI workspace with controlled access.

F19 Reuse outcome measurement

Closes the loop on Reuse Scout's value: track when a candidate is actually re-used. Feeds scout precision tuning and the portfolio "top reuse assets" view.

Wave-6 SHIPPED 2026-06-01: Reuse-outcome measurement shipped — reuse_catalog gained measurement columns (including portfolio_shareable) plus v_portfolio_reuse_outcomes. A synthetic reuse-hit produced a measured outcome_bucket='adopted' row visible through the F17 portfolio view, then cleaned up. Ref: aggregator run decdfa02.

What gets built

• reuse_candidates gains: actioned_outcome (text), reused_in_engagement (text), time_to_reuse (interval), effort_saved_estimate (qualitative tier — small/medium/large).
• SA records the reuse when picking up a pattern for a new ADR.
• Library Curator aggregates into the portfolio "top reuse assets" tile.
• Reuse Scout tuning loop: precision = actioned-and-reused / surfaced.

F21 Customer-facing compliance-evidence export (signed PDF + Library extract)

Per Charlie's ruling: closeout artefacts are always handed back to the customer. This is the customer-facing closeout bundle.

What gets built

• compliance-export skill bundles: ADRs (ratified, with body), engagement-scoped decisions, comms_drafts (sent only), agent_runs metadata (with hash-chain attestation per F3).
• Default destination: signed PDF + Library Curator extract. Signed PDF for the customer hand-back, Library extract for internal Microsoft pattern accretion.
• Alternative destinations pluggable per engagement: Purview, SFTP drop, custom.
• Hash-chain attestation gives the customer cryptographic evidence the bundle is unmodified.

Closeout coupling

Invoked by the engagement-closeout ceremony in F15. Output drops into the customer-handover process.

W9-A.F21 SHIPPED 2026-06-02: Signed compliance-evidence handback bundle for the bound engagement <engagement> (engagement_code placeholder; on-disk pack is the dev/test env). Bundle w9-f21-handback-bundle.zip (12 920 B, sha256 4d2c2ae3…43a9) contains PDF + library-extract.json + manifest.json; library-extract has 33-ADR index + chain-snapshot pinned to row 5c77ad80… (row_hash d3db63f7…dec36 @ 283 rows, re-verified live). Composed by CoS (compose audit 5c77ad80-7007-4a4f-b28e-c2df53698519). Steward signed the zip with KV haleon-attest-priv-pem (RSA-2048, PSS / SHA-256, salt=MAX → 256-byte detached sig); verified end-to-end with KV haleon-attest-pub-pem — VERIFY: OK. Tamper-probe (single-byte flip) correctly rejected on both signed artefacts — signatures genuinely bind content. 3-section content spot-check passed (zip listing, library-extract structure, PDF %PDF-1.4 header + %%EOF trailer); generic-framing intact (no customer-name leak; "loop" hits are historical-ADR titles, not Loop-build leaks). W8 mirror-genesis seeding gap-note folded in same signing pass: mirror-genesis-gap-note.md (1 701 B, sha256 d9196bc2…b648) separately signed + verified + tamper-probed OK; gap documented, NOT applied (mobilise-engagement edit is a separate substrate item). No mirror push — retrievable-from-laptop-disk + sig-verify + content spot-check is sufficient per parent steer. Audit run 2e71be6d-8c50-4e62-ba1c-14119bce2fe7 (two-phase; detail_ref = CoS compose run per soft-FK; sp_verify_chain OK, chain head @ 286 rows) · decision fe45f5f3-6db2-447d-8ce3-fabd36fb3a7f.

F23 Unsurfaced-integration scan (one ADR with YES/DEFER/NO rulings)

Single ADR with a YES/DEFER/NO ruling per candidate integration. Stops "should we use X?" being a recurring open question.

Wave-5 SHIPPED 2026-06-01: SA-ADR-F23 ratified via parent delegation under Charlie's pre-delegated authority (adrs d653cde5-3fde-4bf8-88d4-a5502df0ea87, m-policies/adr/SA-ADR-F23-UNSURFACED-INTEGRATIONS.md). 20+ candidates across 7 sub-categories; machine-readable companion m-policies/adr/integrations.yaml + ADR INDEX.md registration delivered. 8 reviewer + 6 compliance asks resolved across two-round substantive gate (substantive re-gate audit 47d10387-ccb3-440e-8441-5a8456a47a69). Override mechanism declared inert pending integration_overrides pack.json schema follow-up (W6+ residual).

Rulings

• YES: Power BI (via F14/F17), M365 Forms (as alternate intake channel)
• DEFER: Viva Insights, GitHub Issues, Slack (pending non-Microsoft engagement), Jira (pending non-Microsoft engagement)
• NO: Project, Planner (consistent with ISS-21), M365 Approvals (per 31 May feasibility test — ApprovalSolution.ReadWrite requires admin consent, unobtainable; see retired F9)

Override policy

Engagement-pack can override a DEFER → YES locally (e.g., a Jira-shop engagement upgrades Jira). Cannot override a NO. Re-review cadence: yearly + on any new engagement stack-mismatch.

F24 Operator-in-spine clarification (ADR + spine-member with class='operator')

Today the Operator (Charlie's hands-on session) performs DB writes via Charlie's hands but emits no agent_runs rows. This is defensible but silent. Per Charlie's ruling: make Operator a spine-member with class='operator'.

Wave-5 SHIPPED 2026-06-01: SA-ADR-F24 ratified via parent delegation (adrs b505985c-f60d-407f-b6a1-9b8ef2122a02, m-policies/adr/SA-ADR-F24-OPERATOR-IN-SPINE.md). New class='operator' + tier='operator' in legal set; non-Clawpilot fallback session_id='operator:adhoc:<utc-iso>'; gap-scan sourced from pg_stat_statements joined to F20 quarterly drill; HS-10 cost-telemetry rollup exclusion + daily integrity-check probe; SchemaMigrationIn row on CHECK-constraint ALTER. 11 reviewer+compliance asks verified across initial + procedural re-gate (re-gate audit d3daf75a-bf3c-447b-81f8-3c6a2ab9839c). Pairs with F25 for full integrity-and-durability triad with F3.

W9-A re-apply SHIPPED 2026-06-02: The Wave-5 claim above presented the SA-ADR-F24 §3 schema delta as shipped, but a W9-C.R9 substrate audit found the live schema contained neither class='operator' nor tier='operator'. Under operator authorisation + ratified SA-ADR-F24 (adrs b505985c-f60d-407f-b6a1-9b8ef2122a02), Steward applied the §3 DDL for real: (1) agent_runs_class_check DROP+recreate → 10 values incl operator; (2) ALTER TYPE haleon.agent_tier ADD VALUE 'operator' (autocommit) → enum_range = 8 values; (3) CREATE OR REPLACE haleon.sp_rollup_cost_telemetry adding operator to the HS-10 cost-rollup exclusion (delta-probe: synthetic operator row included under old filter=1, excluded under new=0). Each DDL emitted its own SchemaMigrationIn row (no-silent-DDL invariant). Verification: synthetic class='operator'/tier='operator' insert via sp_create_agent_run succeeded (proves acceptance); row retained + documented as the first operator-class genesis row because agent_runs is a hard append-only hash chain (role grants INSERT/SELECT only, no DELETE). Correction-class audit run 4b8fc0a8-02ae-4b31-b173-3a0f93177712 (two-phase; sp_verify_chain OK @ 288 rows) · decision d2d38882-9403-40a2-a493-511de39c3f5c. Generic-process framing (bound engagement <engagement>).

What gets built

• ADR documenting the choice and rationale.
• ALTER agent_runs_class_check to include 'operator' in the legal class set.
• Operator session emits class='operator' rows for meaningful actions (DDL applies, manual scout_enable_flags flips, Approvals overrides).
• HS-10 cost-telemetry rollup exclusion list extended (Operator actions are governance, not delivery cost).

Pairing with F3

The integrity story is incomplete until the spine answers "who wrote this and what class" for every mutation, including human-driven ones.

F25 ADR: "Audit spine substrate is non-durable by design"

Captures Charlie's 30 May 2026 DR-not-needed ruling as a deliberate, auditable position. Closes the silent posture; an auditor asking "where's your DR plan?" gets a coherent answer rather than a gap.

ADR position

The engagement substrate is reproducible from M365 / ADO / MSX / GitHub primary sources. The hosted DB is an accelerator + integrity-attested evidence trail (per F3), not a system-of-record requiring disaster recovery. Loss of the hosted DB is recoverable from primary sources; loss tolerance is “unbounded” (not “not applicable”) — the system functions, just with rebuilt history.

Wave-5 SHIPPED 2026-06-01: SA-ADR-F25 ratified via parent delegation under Charlie's pre-delegated authority (on-disk at m-policies/adr/SA-ADR-F25-AUDIT-SPINE-NON-DURABLE.md; adrs substrate row written in parallel by wave5-steward). Primary-source registry covering 16 state classes + closure clause for unregistered tables; Operator-authored chain-of-custody rebuild ceremony per F24; canonical triggered_by shape spine_rebuild:engagement=<name>;prior_chain_head=<sha>;replay_horizon=<iso>;genesis_v=<n>; explicit unsuitability for HIPAA/SOX/GDPR/FINRA-retention-bound engagements with F11 mobilise-time gate. 8 reviewer+compliance minor asks + Steward §4(a/b/c) substrate-accuracy corrections folded across initial + procedural re-gate (re-gate audit 9cf1fde4-3f82-4a04-b269-8e3cfc66b683). Completes the integrity-and-durability triad with F3 + F24.

F30 Portfolio metrics in the 5-3-2-1 brief header

Replaces the F17 Power BI publish path (ruled design-only / won't-build). Cross-engagement portfolio metrics are folded into the header of the daily 5-3-2-1 brief instead of a standalone BI surface.

What gets built

• The daily-brief skill gains a header block sourced from the shipped F17 portfolio views + aggregator (v_portfolio_*).
• Header answers a real cross-engagement question (e.g. open-ADR counts, reuse adoption) at generation time.
• Rendered onto the engagement's Loop brief page; generic <engagement> framing.

W7-A SHIPPED 2026-06-01 18:15Z: loop-publish.ps1 brief-source flow gains a portfolio header strip rendered above the empty-bundle guard (KPI pill row + freshness chip). Cross-engagement aggregates source the shipped F17 portfolio.v_portfolio_* view tier (engagements_active, open_adrs, runs_24h/7d, reuse_hits, burn_day) + aggregator status (partial 2/2 @ 15:21Z staleness guard so a stale snapshot never reads as a real zero). Live-published to the dev/test Haleon Loop workspace (page title W7-A Daily Brief (dev/test)) and round-trip read-back confirmed — all 6 metric values match the direct SELECT exactly. Audit 62c74ff8-e219-4f92-b280-a93c90e2db14 (live publish); companion audits e3966262... (code change) + 86b494b7... (discovery). Seal lag W7-A→F30 = ~2hrs (live publish 18:15Z → article seal 19:0XZ); cause: orchestrator did not chain seal-immediately on ship confirmation. Fix: shipped-rolling-block at the top of W7 + per-ship seal-on-confirm SOP, effective W7+.

F31 Use-case-level tracking (one level below engagement)

A tracker at the use-case granularity for a given engagement — the same shape as engagement/project tracking, one level down.

What gets built

• W8-A scope (Charlie steer 2026-06-02): tracking lives in the DB schema (portfolio. + per-engagement haleon.) — ADO and Loop reporting layers can be added later if needed.
• Per-use-case state model mirroring the engagement-level lifecycle (lifecycle table + state-transition trigger + audit-row class extension).
• One use-case tracked end-to-end under a dev/test engagement with at least one recorded state transition (live SELECT proves the row + transition).

F32 Loop page templates + defined hierarchy

If we publish Loop reports daily they must be standardised. A template per page type and an explicit page hierarchy.

What gets built

• Templates for: front-page / overview, and each recurring report type.
• A defined page hierarchy (which page parents which).
• Each template instantiated as a real Loop page in the dev/test notebook and read back; generic <engagement> placeholders.

W7-C PARTIAL 2026-06-01 (design-complete; live-Loop instantiation deferred to 2026-06-02 operator-attended browser session): All 7 templates (front-page overview, daily-status, weekly-rollup, steerco-prep, ratified-ADR-digest, incident-postmortem, engagement-survival) committed to canonical home ~/.copilot/m-skills/loop-publish/templates/ as W7-D-ratified design files with rule-aware regions (R1 task-state isolation, R2 archive-on-replace slot, R3 /ws/-only links, R4 hash-stable content-section, R5 last_published_content_hash footer, R6 leaf-class retention metadata, R8 CAPS-as-headings); generic <engagement> placeholders; cross-cutting chrome conventions (top HTML-comment metadata block, MANIFEST + AUTHOR NOTES split footers, branch-distinct box-drawing weight); daily-status previously instantiated live in Haleon dev/test workspace (audit 57ca7614-aa42-45f8-8e4d-3f1ea04bbd51). Audit chain: rotation 7e31720d-2348-4b1d-aa04-b38235cbdba2 · design-commit 0e578f7f-97c3-44ab-8bbd-3ccd0d11abf2. Overnight BUG-001 constraint (browser-MCP re-prompt; operator asleep) prohibits the 5 remaining live Loop instantiations + the round-trip read-back from completing tonight. Flips to shipped on (a) all 7 templates live in dev/test Loop with read-back and (b) SA review-checklist PASS across all 18 checks per template.

F33 Loop governance rules (when a page may update)

Rules for Loop page updates. Charlie's lean: a page updates only when its assigned tasks are complete; newly-created reports archive-and-replace the old ones. Charlie is explicitly open to push-back — SA adjudicates and Charlie ratifies.

What gets built

• An ADR capturing the update / archive policy (routed through the Reviewer gate).
• Enforcement in the publishing skill: refuse to update a page with open assigned tasks; archive-on-replace step for superseded reports.

W7-D SHIPPED 2026-06-01: ADR-W7-D ratified by SA + Reviewer + Charlie — rules R1 (task-state isolation), R2 (archive-on-replace), R3 (/ws/-only links), R4 (content-hash idempotency), R5 (publish-cursor CAS), R6 (leaf-class retention 8 default / 4 for engagement-survival), R7 (capability-gate), R8 (CAPS-as-headings) · intent-ratify audit 0a41d6ff-3a12-4809-9c8c-e4feea7920e1 · ratification decision 7b46cd41-1790-4260-b180-eaddd1ea39c8. W7-D.1 IMPL-DEPTH ADDENDUM RATIFIED 2026-06-01: follow-on ADR f02af754-0ad1-4c3d-a0d7-a5e463c9181f ratified (decision 28efcc82-156d-4e6b-9542-63974788a996, audit edbc8656-8f49-4280-8476-46781e6cd175) — tightens the publish-skill enforcement contract (preflight checks, CAS semantics for republish, force-publish escape-hatch wording, force-publish-stale variant for survival pages). Enforcement now binding on F32/F34 live publishes.

F34 Engagement bootstrap-survival Loop page

An add-on to the project-level Loop pages: a single page holding everything needed to recreate an engagement after laptop failure. Loop sits behind Entra, so it survives a wipe and is recoverable via UPN sign-in.

What gets built

• Recovery essentials on one page: bootstrap-stub URL, KV secret names, MCP names, pack / workflow pointers, role-brief list, sync location, recovery order.
• Cross-checked against the F27 laptop-continuity playbook; generic framing.
• Survival page exists in the dev/test notebook and is read back.

W7-E PARTIAL 2026-06-01 (design-complete; live-Loop instantiation deferred to 2026-06-02 operator-attended browser session): Survival-page schema W7-E-v1 ratified by SA (Charlie-gated leaf-class addition engagement-survival with retention=4 per W7-D R6); engagement-survival template committed to ~/.copilot/m-skills/loop-publish/templates/engagement-survival.md (generic). Haleon instance (the first survival page) authored as markdown source at ~/.copilot/session-state/488d3c5d-.../files/survival-pages/haleon-aiac.md — populated §1–§9 of the W7-E schema (engagement identity, bootstrap, KV secrets, MCPs, pack/workflow pointers, role briefs, corpus sync via F35, audit-spine DB, recovery-order runbook) + cross-links to F27 laptop-continuity. Audit chain: rotation 7e31720d-2348-4b1d-aa04-b38235cbdba2 · design-commit 0e578f7f-97c3-44ab-8bbd-3ccd0d11abf2. Overnight BUG-001 constraint prohibits the live Loop publish + read-back. Flips to shipped on (a) survival page live in dev/test Loop with read-back and (b) preflight validation rules from W7-E §Validation green (presence + freshness gates).

F35 Durable corpus sync (skills / briefs / docs → Azure Storage)

The expectation that all skills, role-briefs, documentation and other critical items are backed up to Azure Storage — with a real answer to how they sync and how often. Today's corpus-sync is 403-broken (storage public access disabled, no private endpoint); only a direct deploy workaround exists and a policy reverts manual re-opens.

What gets built

• A durable conduit (private endpoint / VNet / managed-identity network exception) — likely infra creation, surfaced to Charlie before provisioning.
• Scheduled two-way sync (Ticker-driven or cron) replacing the swa-deploy workaround.
• Run-time download + remote update pattern (Azure Storage as source of truth) per the F27 continuity idea.
• Verify: a changed skill / brief pushes to blob and reads back through the durable path.

W7-F SHIPPED 2026-06-01 (Phase 5 probe-pass + Phase 6 mirror regen): Container Apps Job caj-clawpilot-corpus-sync provisioned on environment cae-clawpilot-uks (Consumption, uksouth) on schedule 0 2 * * * UTC; two narrow-role UA-MIs (mi-clawpilot-corpus-flipper for the storage-firewall flip + mi-clawpilot-corpus-rw for blob read/write) each holding the custom least-privilege role Storage Network Flipper (corpus) scoped to stclawpilotcorpusuks; watchdog Logic App la-clawpilot-corpus-watchdog implements the three-layer close (job-success / job-failure / timeout) to guarantee the firewall always re-closes. Probe-pass audit 0b81ce9d-b89c-4c84-905a-e7baa9aad64b measured open_window_ms=39000 (well inside the 5-min budget). Phase 6 SWA-mirror regen audit 5d0230d9-8f09-4c36-a38d-bbc10adc6067 — live mirror serving at https://jolly-dune-00bde4103.7.azurestaticapps.net/ (read-only public surface; bootstrap-stub fetch path for F34 survival recovery). GH→Azure runtime pivot: EMU-policy blocked GitHub-hosted runners (audit 8a1d976e); pivoted to Azure-native Container Apps Job runtime, audit 0b81ce9d proves pass; orphan GH workflow preserved with archival banner at commit 2db30dca for provenance. Cost £0/mo marginal preserved (Consumption + 22-hour-daily firewall-closed window).

F36 Milestone recognition tracker + thank-you drafting

Flags general milestones (not official project milestones — just things getting done), reminds Charlie, and helps draft genuine thank-you / congratulations notes, including notes to people's managers recognising good work.

What gets built

• Milestone detection / recording + a reminder surface.
• Draft notes via the outbound-voice skill (peer variant + manager variant) so they sound like Charlie.
• Privacy: drafts are previewed to Charlie before any send; never auto-sent.