c146 plan: the Config page, and an agent that drafts the file

Standing: 2026-11-13. The calls were walked and the cycle kicked off. Phase 2's mock is built, and review stop 1 is ruled (§ Review stop 1). C9 waits for Mark Peterson; Q6 waits for Tyler.

What's asked

Mark wants one page in the native app that manages qcontrol's configuration file, config.yaml. It has three modes:

1. Edit it here. The file appears in an editor. A library of starter files can fill the editor.
2. The company governs it. The configuration comes from the company's Qplane.
3. Point to a published file. A file hosted at a public URL.

An agent can prepare the file over MCP from the person's high-level instructions without error. Under ruling R4, the agent prepares a draft that has been checked, and the person applies it. "Without error" means two things:

• An invalid draft never reaches the person.
• The agent has what it needs to be right the first time: the schema, worked examples, and errors it can act on.

Prior art

Rulings (Mark, 2026-11-13)

• R1 (C1). The URL mode fetches the file once. c138 ruling 4 holds. The page shows the address, fetches the file, shows it, checks it, and asks the person to confirm. From then on the file is local. Check for changes fetches it again and shows the difference before the person confirms. Nothing follows the address on its own.
• R2 (C2). The names and the first pass come from Policy Config. Mark misspoke on "policy file". The prior art is c121's Config File page. The mock takes its vocabulary as it is: Config File, live, draft, proposed changes, Import, Download, versions, staged then applied. The mode labels are drafted in that vocabulary in the mock and shown at review stop 1.
• The file (asked with R2). It is qcontrol's config.yaml. Mark: "I think the config.yaml is the shape of the file?" This is the working reading. Tyler is asked whether the company's policies reach the sensor through this file, or alongside it.
• R3 (C3). A V1 page under This machine, beside Sensor. It is not a Dev page, and the lean build has it. This overrules c138 ruling 6 for Config.
• R4 (C4). The agent drafts; the person applies. The agent never writes the file. It proposes a draft that has been checked. The page shows the difference between the draft and the current file, and the person presses Apply or Discard. This keeps the guide's rule of pointing, never pressing (c145, Simulation mode).
• R5 (C5). The app's own MCP server carries the tools, because the page is in the native app. The page and the agent share one checker and one record of changes.
• R6 (C6). Validation is asked of qcontrol. Assume the app integrates with qcontrol and can ask it to check a document, getting back each error with its key path and line. This is an ask to engineering. The mock and the stories use a fixture checker until it exists.
• R7 (C7). The draft is always the whole config.yaml, shown as a difference against the current file: one file, one picture. Include files are left as they are.
• R8 (C8). Use the editors that exist; build nothing custom.
  • Native: gpui-component's Editor for editing and its diff view for a draft, inside QGUIkit's EditorFrame.
  • The web mock: the layer's UxEditorFrame and UxCodeBlock to read, and a plain textarea to edit, as Policy Config's Import does.
  • A fuller editor comes later.
• C9. When the company manages the file: open, for Mark Peterson. Mark's idea: the person can tell the agent "tell me first, so I can fix it on my own". The agent then explains the change instead of drafting it. First pass, until Peterson answers: the draft is refused with "Managed by . Changes are made there." The agent can still read the file, explain it, and say what would need to change.
• Starters (asked with R4).
  • One library, hosted by Qpoint at a public address. The app highlights a curated set. More files may live online without being highlighted.
  • Manual mode loads a starter into the editor. URL mode fetches any address, Qpoint's included.
  • First set: Recommended (what most people need) and per-role variants: a developer laptop and a data or analyst laptop. The contents grow over time.
  • Configurations a security professional builds from compliance frameworks belong to the plane, later.
• Overlays go to their own cycle. These are layers that only tighten the company's configuration, and agents on personal accounts kept out of company directories and knowledge bases. Opened as c148 Config Overlays, stage 1. Not handled here.

Review stop 1 (Mark, 2026-11-13)

• Q1. The labels stay: Edit here · Managed by your company · From a published file.
• Q2. A published file replaces config.yaml whole, with its origin record at the top, and the old file is kept as a version. Guide 05's conf.d/ landing is superseded.
• Q3. The starters are in the editor's tray. With no file, the page also opens on a Pick a starter step.
• Q4. The endpoint keeps a versions list, with Restore on each.
• Q5. Ask your agent stays on Config. Help › Getting started gets the connect line (Phase 3).
• Q6. The "Policy Config v13" label on HQ's file is an assumption until Tyler answers whether the plane delivers Policy Config to the sensor as config.yaml (§ Asks).

Phases

Phase 0. Shared ground

• Ask Mark Peterson about C9.
• At kick-off, open qnative's twin cycle (c10) for Phases 3 and 4.
• Draw the sketch, app/pages/cycles/design/sketches/c146-config.vue: three sources, one file, one checker, the agent's draft and the person's Apply.
• Write the story, app/data/stories/c146.ts.
• Amend the Config row of c130 shape.md (V1, not Dev).

Phase 1. The document contract and the starters

Everything an agent needs to draft a valid file the first time, read from qconfig on main:

• The reference. Every key with its type, its allowed values, its default and what it means; predicate syntax (rules.rs); how behaviors fold (resolve.rs); includes; secret references. It is generated from file.rs, so it doesn't drift. JSON for the tools, Markdown for people.
• The examples. The stock document's commented examples, each uncommented and checked on its own.
• The intents catalog. The person's plain instructions, each with the fragment that answers it. This is the eval set. Examples:
  • "audit everything Claude Code does"
  • "send events to my OTel collector at …"
  • "also log to a file"
  • "enforce OpenShell for Cursor"
  • "keep my API key out of the file"
  • "turn the tray off"
  • "only file writes and exec events to the collector"
  • "stop watching this harness"
  • "what is this file doing right now?"
  • "start me from the developer-laptop starter"
  • "why was my draft refused?"
• Errors written for an agent. Each gives the key path, the line, what was expected, and the nearest valid key ("did you mean behaviors?"). This answers item 2 of the 2026-11-13 guide walk.
• The starter library. Three config.yaml files, each one checked: Recommended, Developer laptop, Data/analyst laptop. Plus a catalog manifest that gives each one's name, who it's for, what it does, and its address. Until the docs site hosts the library, it is served from a fixture address.

Phase 2. The mock (medium A, the design site)

app/pages/pages/native/config.vue in the native skin, phase native. It reads the worlds through useNativeWorld. It is built on Policy Config's Config File: the same code view, version picker, Download and Import. It shows two views of one configuration, as written and effective, and every state of the three modes.

Edit here

• no file: the stock document is in force
• pick a starter
• valid
• invalid, with the problem on its line
• unsaved edits
• applied
• an agent's draft: who proposed it and when, the difference, Apply or Discard
• the previous version, with Revert

The company manages it

• not connected
• signing in
• connected and read-only, saying who manages it
• refused
• plane not answering
• an agent's draft refused, with the sentence from C9

From a published file

• an address entered, or a starter picked from the library
• fetching
• shown in full
• invalid
• confirm
• written, with its origin record (the address, the time, the hash)
• check for changes, with the difference

An Ask your agent strip carries the MCP line and three example instructions. A shot program (scale: 2, clip: ".native-window") files the captures. Review stop 1: the mock, the mode labels in Policy Config's vocabulary, the starter picker.

Phase 3. The native page (medium B, qnative c10)

• The page on gpui-component's Editor and diff inside QGUIkit's EditorFrame (R8).
• The three modes, run on synthetic data and the fixture plane. On the synthetic source, nothing is written to this machine (c138 R4's guard).
• A story and a region-text test for each state, failed and loading included.
• Captures wiped against the mock (c132 D7).

Phase 4. The MCP tools (qnative c10)

There is no write tool. Apply, Discard and Revert are the person's buttons (R4). The server instructions gain a config section:

• read the reference first;
• check before proposing;
• say what the draft changes in the person's words;
• point at Apply and never press it.

Phase 5. The eval and the walk

• A Claude Code session connects through the Help page's line and is given each instruction in the intents catalog, on a synthetic world.
• It passes when the first proposal checks clean, its fragment matches the catalog's, and the page shows the draft ready to Apply.
• Record the first-proposal rate for each instruction.
• Then Mark walks it as he did the guide on 2026-11-13.
• Review stop 2.

Phase 6. Record

• Captures, the story and the Outcome.
• Guide 05 rewritten from a proposal into a contract.
• c145's configure step pointed here.

Out

• Following an address over time (R1).
• Overlays and stricter local layers (c148).
• The plane's credential exchange (c131 D13, c134).
• Authoring a company's configuration on the web.
• Any change to qcontrol: asks only.
• A custom or fuller editor (R8).

Asks of others

• Engineering:
  • a check entry point that returns errors with their paths and lines (R6);
  • who may write the file when the monitor runs elevated;
  • whether a changed file is picked up without a restart;
  • that ui.tray governs the one menu-bar icon, whoever draws it: the app honours it, and qtray doesn't run beside the app (the walk's W1, with c131 D7).
  
  Until these are answered, the page says honestly when a change takes effect.
• Tyler: do the company's policies reach the sensor through config.yaml (Q6: the mock labels HQ's file "Policy Config v13" on that assumption)? What in the file says that a plane is expected (also c145's question)?
• Mark Peterson: C9.
• The docs site: hosting the starter library at a public address.

Related

• c121 D13 and D26: the prior art
• c138: the outline, ruling 4
• qnative c3 Guide 05
• c145
• c148
• c131 D13 and D17
• c134
• market-analyst problem:fleet-scale-compliance-state