← Design · c133

review-9-wave1.md

c133 · The four trainings c144's wave 1 wanted (2026-11-13)

Written at Mark's word ("Yes, write them"), asked in the c142 session after c144 built its six wave-1 scenarios. Four of them named a training they needed and had none. All four were written with the /training skill.

TrainingPolicyScenarios it answersWritten for
Approved model providers (T-PROVIDERS-1)Approved model providers only (P-PROVIDERS)S5F-F in the base world (Priya's request to deepseek.com, blocked) and TH-S5-b2-1 (User A's ticket to api.refundhelper.example, Observed)
Skills that update themselves (T-PROVENANCE-1)MCP servers and skills are pinned to reviewed versions (P-PROVENANCE)S3, S2TH-S3-b2-1 (repo-tidy 1.5 where 1.4 is pinned) and TH-S2-b1-2 (sheets-pro-mcp, nothing pinned)
Ask before an agent sends or publishes (T-APPROVAL-1)Consequential tool calls require approval (P-TOOL-APPROVAL)S4, S1, S3TH-S4-b3-1 (github.create_gist, public: true), TH-S1-b5-1 (gmail.send) and TH-S3-b5-2 (curl to a paste site)
Unattended agents and their spend (T-SPEND-1)Spend stays under the ceiling (P-SPEND)S6TH-S6-b2-1, b3-1 and b5-1 (Ravi's loop at $14, $1,240 and $3,800)

First: one addition to the lab world, after the walk

F-I, added 2026-11-13 at Mark's ruling (call 1 below, D60):

  • Hana's Claude Code on mac-eng-05 (Engineering) merged pull request #517 into main through GitHub MCP, with approval set to never.
  • GitHub MCP is sanctioned, so nothing else is wrong.
  • It is Observed (the policy observes organisation-wide), with its session S-8 (release branch cleanup, 19 tool calls), marked c133.
  • The findings list now holds 25.

The checks pass after it: theatre-check 190/0, tours-walk 455/0, c123 metrics 49, and the governance pages, Reports and the policy's page all serve. The approval training was taken end to end on F-I, and two captures were added (scripts/shot-programs/c133-approval-seed.json). The collection capture above was taken before F-I, so it still shows no finding for the approval training.

As written before the walk, none of these had added a finding to the base world:

  • P-PROVENANCE and P-SPEND are Off for everyone there. A finding under an Off policy would not be honest. Their findings exist in the simulation, where the scenario's set puts the policy at Observe for its cast.
  • P-TOOL-APPROVAL observes organisation-wide but has no finding. Its three simulation findings cover it.

The preview page links those three to the library, as it does for a topic. In the simulation, each is taken from its own finding.

Where to look

WhatWhere
Providers on its base finding/pages/phase4/mock/finding-detail?findingId=F-F
Providers in the simulation (S5)TH-S5-b2-1
Skills that update themselves (S3)TH-S3-b2-1
Ask before an agent sends or publishes (S4)TH-S4-b3-1
Unattended agents and their spend (S6)TH-S6-b2-1
The collection and the scene gallery/pages/phase4/trainings
The published JSON/api/trainings

Captures: the thread "The four trainings c144's wave 1 wanted…" (scripts/shot-programs/c133-wave1.json, fifteen shots).

What was done

  1. Four files in app/data/trainings/en/. Each takes 3 minutes and is v1, with four steps (what happened, why it matters, what Qpoint does, what to do instead), four questions, and a Library section that rewords the first step.
    • The text reads true whether the act was blocked or not. That comes from the slots.
    • The right answers are in different places in each check (D34).
  2. Slots keyed by policy. Each finding shares its resource kind with another policy's: three are mcpServer like P-MCP's, and spend is provider like P-PROVIDERS'. So slots.ts gains four entries in POLICY_SLOTS:
    PolicySlots
    P-PROVIDERSprovider, approved, providerGot, outcome, blocked
    P-PROVENANCEcomponent, pinned, pinnedSentence, outcome, blocked
    P-TOOL-APPROVALtool, outcome, blocked
    P-SPENDceiling, ceilings, outcome, blocked

    The slots a policy's configuration alone fills (the approved list, the pinned list, the ceilings, and T-INJECT-1's heuristics) are now one map, POLICY_CONFIG_SLOTS. The library reads that map instead of naming P-PROMPT-INSPECT. The rule is in authoring.md §Slots.
  3. Eleven scenes, catalogued and mapped:
    • provider-request, provider-terms
    • version-load, version-trust, pin-version
    • unapproved-call, consequential-calls, approve-call
    • spend-ceiling, retry-loop, agent-limit

    policy-modes, mode-observe and mode-ask are reused. The scenes that name the finding's own thing (the provider, the skill, the tool) name it in general when the library has no finding, as hidden-instruction does. The catalogue holds 35.
  4. Voice. Every filled sentence, scene label and library reading went through check-brand-voice (productUI), with zero violations. A scratch check filled each training on every finding it answers, in the base world and in each scenario with each replay: 13 distinct readings, no slot left unfilled and no voice violation. The preview page's Voice column reads pass for all four.
  5. Taken end to end in the browser pane:
    • T-SPEND-1 from its finding's strip, through the four steps. A wrong answer brings the retake, which points back to step 3. Then all right, Finish and record, and the history row ("training completed · passed, 4 of 4"), with the finding still open (D9).
    • T-APPROVAL-1 and T-PROVENANCE-1 in the simulation, through the steps, the check and the record.
    • T-PROVIDERS-1 from F-F's strip in the base world, through to the history row.
    • On its own from the library: all four read 4 of 4 steps and 4 of 4 questions, with nothing left out.

    Checked in dark mode. The only console errors were two hydration-mismatch warnings that the preview page already showed before this change.

Two fixes on the way

  • "Tell Theatre" in the simulation. A training's contact is the policy's owner, read as the last person to change the policy. Inside the simulation that was c144's set or replay, whose change actor is Theatre. So the trainings on S2, S3, S6 and every replay would have told the person to ask "Theatre". ownerOf now skips that actor, as it already skips qdash and clock, and those readings say IT.
  • The trainings preview page crashed after a dev restart ("Cannot read properties of undefined"). Two imports used only in its template, PLANNED_PILOTS and isScene, were dropped. That is the known template-only-import quirk. Both are now bound in the page's script.

The calls for you

  1. No base-world findings for these three. P-PROVENANCE and P-SPEND are Off in the lab world, and P-TOOL-APPROVAL has none. Proposed: leave the world as it is. These trainings are met in the simulation. If you want them in the base world as well, P-TOOL-APPROVAL could gain one row the way F-H was added. The other two would need the policy switched on for a team.
  2. The title "Ask before an agent sends or publishes". c144 asked for "Ask before an agent publishes". But S1 (gmail.send) and S3 (curl to a paste site) raise the same policy, and both send. Proposed: keep the wider title.
  3. Advice that names what an agent offers. T-SPEND-1 says to use "your agent's own limits where it has them, such as a maximum number of turns". T-PROVENANCE-1 says to "install skills and servers at a fixed version, not the latest". Both are worded so they hold for any harness, and neither names a setting. Proposed: keep them general. Name the setting per harness in a later version, if the native app knows the harness.
  4. The native app. None of the four is bundled in qnative yet, and the native simulations S2 to S6 are not built yet. Proposed: bundle each training with its native scenario as that scenario is built, as T-INJECT-1 went with S1.

Passed to c144

The c144 session owns these, and they were sent there. Both were done the same day in c144's lab, uncommitted until Mark rules: the scenarios list the four trainings in trainings, and StepNote has their titles. The held call's evidence now reads " held for approval: …", with the same fix for P-MCP, P-FILES and P-DATA-BOUNDARY when they stop the act. What was sent:

  • Each scenario's trainingsWanted now has a training to move into trainings:
    • S3: T-PROVENANCE-1, and T-APPROVAL-1 for beat 5
    • S4: T-APPROVAL-1
    • S5: T-PROVIDERS-1
    • S6: T-SPEND-1
    • S1: T-APPROVAL-1 for beat 5
    • S2: T-PROVENANCE-1
  • In the replay at Enforce, the detector's evidence for P-TOOL-APPROVAL still reads "ran without approval", though the call was held.

A small thing in the world

F-F's session S-5 has a summary that repeats its evidence ("Request to deepseek.com blocked at 09:27"). So the first step reads "during a session: Request to deepseek.com blocked at 09:27. qcontrol recorded it as: Request to deepseek.com blocked at 09:27; …". That is the fixture's text, left as it is.

Ruled (2026-11-13)

Mark walked the four calls one at a time in the c142 session.

  1. Reversed: add the approval finding (D60). The rule that kept F-H (the policy is on, so a finding is honest) holds for the approval policy too. F-I was built the same day. It is Hana's merge, not Dev's from the example in the walk, because Dev is on Finance and a pull request reads oddly there. P-PROVENANCE and P-SPEND stay simulation-only while they are Off in the lab world.
  2. Keep "Ask before an agent sends or publishes" (D61).
  3. Keep the advice general for now (D62). Named settings come in a later version, filled from {agent}, once each tool's current settings are checked.
  4. Agreed: bundle each training with its native scenario (D63), when c144's Phase 2 builds S2 to S6 in the native app.

Qpoint Brand Style Guide