@stravica-ai/digital-operator-pa 0.1.35 → 0.1.37

package/dist/engineering-pa-cli/src/pa/cli.mjs

@@ -326,12 +326,15 @@ Exit codes (tooling standard §6):
 const WORKSPACE_USAGE = `pa workspace — workspace server lifecycle
 
 Usage:
-  pa workspace start [--port N] [--no-open]   Start the workspace server
-  pa workspace stop                            Stop the running server (refuses if supervised)
-  pa workspace restart [--port N] [--no-open]  Restart (supervisor-aware: launchctl kickstart / systemctl restart)
-  pa workspace status                          Show server status (supervisor-aware)
-  pa workspace open                            Open the workspace URL in a browser
-  pa workspace -h, --help                      Show this help
+  pa workspace start [--port N] [--host H] [--no-open]   Start the workspace server
+  pa workspace stop                                        Stop the running server (refuses if supervised)
+  pa workspace restart [--port N] [--host H] [--no-open]  Restart (supervisor-aware: launchctl kickstart / systemctl restart)
+  pa workspace status                                      Show server status (supervisor-aware)
+  pa workspace open                                        Open the workspace URL in a browser
+  pa workspace -h, --help                                  Show this help
+
+Bind host defaults to loopback (127.0.0.1). Use --host <addr> (or the
+WORKSPACE_HOST env var) to expose the workspace on another interface.
 
 When the workspace is supervised by launchd (~/Library/LaunchAgents/com.dave.workspace.plist)
 or systemd (~/.config/systemd/user/dave-workspace.service), \`stop\` is refused and \`restart\`

package/dist/engineering-pa-cli/src/secrets/vault.mjs

@@ -790,6 +790,16 @@ export async function sopsDecrypt(paths, filePath) {
  * scoped-vault fixtures use). Order is stable, duplicates deduplicated.
  * Returns an empty array on any read failure. This helper only feeds a
  * diagnostic message and must never throw over its own IO.
+ *
+ * NOTE: this reads the UNION of recipients across every creation_rule
+ * in the file. Scoped `.sops.yaml` configs typically declare one rule
+ * per encrypted file, and a caller who is a recipient in ONE scope but
+ * not another still matches this union. That is why the false-absence
+ * diagnostic surfaced on ops-01 (w-2026-09-03-dave-011): the caller's
+ * pubkey belonged to the seo-ops rule, not the hq-estate rule, but the
+ * union read showed it. Use `recipientsForTargetFile` to get the list
+ * for a specific file instead; the union stays here as a strict
+ * fallback for configs the narrow parser cannot recognise.
  */
 export function readRecipientsFromSopsConfig(sopsConfigPath) {
   let text;
@@ -812,31 +822,204 @@ export function readRecipientsFromSopsConfig(sopsConfigPath) {
   return out;
 }
 
+/**
+ * Parse creation_rules from a sops config file and return the recipient
+ * age pubkeys for the first rule whose `path_regex` matches the given
+ * encrypted file's basename. Returns null when the parser cannot pick a
+ * matching rule (caller falls back to the union read). Returns an empty
+ * array for a matching rule whose `age:` field is empty.
+ *
+ * The parser is deliberately narrow: it splits into blocks starting at
+ * `- path_regex:` lines and reads two fields per block, `path_regex`
+ * and `age`. Both inline (`age: "age1a,age1b"`) and folded multi-line
+ * (`age: >-\n  age1a\n  age1b`) shapes are handled: the two forms the
+ * estate's provisioning tooling emits. YAML this parser cannot
+ * recognise falls back to the union at the caller, so a partial config
+ * still produces a truthful message rather than a silent absence claim.
+ *
+ * Root-cause cure for w-2026-09-03-dave-011: `readRecipientsFromSopsConfig`
+ * unioned pubkeys across every creation_rule, so on ops-01 the caller
+ * key (recipient of seo-ops, not hq-estate) appeared in the printed
+ * "recipients" list, contradicting the "not in the recipient list"
+ * assertion. Scoping the recipient list to the actual target file's
+ * matching rule keeps the wording honest.
+ */
+export function recipientsForTargetFile(sopsConfigPath, targetFile) {
+  let text;
+  try {
+    text = readFileSync(sopsConfigPath, 'utf-8');
+  } catch {
+    return null;
+  }
+  if (!targetFile) return null;
+  const targetName = basename(targetFile);
+  const lines = text.split('\n');
+  const rules = [];
+  let current = null;
+  let foldingAge = false;
+  const ruleStartRe = /^\s*-\s*path_regex:\s*(.+?)\s*$/;
+  const inlineAgeRe = /^\s*age:\s*"?([^"]*?)"?\s*$/;
+  const foldedAgeStartRe = /^\s*age:\s*>-?\s*$/;
+  const ageInlineExtract = /age1[0-9a-z]+/g;
+
+  for (const line of lines) {
+    const ruleStart = ruleStartRe.exec(line);
+    if (ruleStart) {
+      if (current) rules.push(current);
+      current = { pathRegex: ruleStart[1], age: [] };
+      foldingAge = false;
+      continue;
+    }
+    if (!current) continue;
+    if (foldingAge) {
+      // Folded block ends at a blank line, a new key at the block's
+      // indent, or a new list item. Anything else is a wrapped value.
+      const trimmed = line.trim();
+      if (trimmed === '' || /^[A-Za-z_-]+\s*:/.test(trimmed) || /^-\s/.test(trimmed)) {
+        foldingAge = false;
+        // fall through so this line can still start a new rule below
+      } else {
+        for (const match of trimmed.matchAll(ageInlineExtract)) current.age.push(match[0]);
+        continue;
+      }
+    }
+    if (foldedAgeStartRe.test(line)) {
+      foldingAge = true;
+      continue;
+    }
+    const inline = inlineAgeRe.exec(line);
+    if (inline) {
+      for (const match of inline[1].matchAll(ageInlineExtract)) current.age.push(match[0]);
+    }
+  }
+  if (current) rules.push(current);
+
+  for (const rule of rules) {
+    let re;
+    try { re = new RegExp(rule.pathRegex); } catch { continue; }
+    if (re.test(targetName)) {
+      const seen = new Set();
+      const out = [];
+      for (const k of rule.age) if (!seen.has(k)) { seen.add(k); out.push(k); }
+      return out;
+    }
+  }
+  return null;
+}
+
+/**
+ * Read every `# public key: age1...` line from an age key file. A key
+ * file with a single identity yields one entry; a file with multiple
+ * identities yields one entry per identity, in file order (the order
+ * sops tries them when SOPS_AGE_KEY_FILE points at the file). Returns
+ * an empty array on any read failure or when no comment can be parsed.
+ * Only feeds diagnostic output: never throws over its own IO.
+ */
+export function publicKeysFromKeyFile(keyFile) {
+  let contents;
+  try {
+    contents = readFileSync(keyFile, 'utf-8');
+  } catch {
+    return [];
+  }
+  const out = [];
+  const seen = new Set();
+  const re = /public key:\s*(age1[0-9a-z]+)/gi;
+  let m;
+  while ((m = re.exec(contents)) !== null) {
+    if (!seen.has(m[1])) {
+      seen.add(m[1]);
+      out.push(m[1]);
+    }
+  }
+  return out;
+}
+
 /**
  * Build the single stderr diagnostic line that names, without ever
  * decrypting anything, WHY a decrypt failed: the scope (or vault path),
- * the caller's age public key (never the private key, never the value),
- * and the scope's recipient list read from the sops config. Falls back
- * to a shorter form when one of those pieces cannot be recovered. The
- * caller still needs a message, and silence on this seam is the defect
- * being fixed (w-2026-09-02-dave-015 part 1).
+ * every candidate age public key the caller's key file contains (the
+ * exact set sops tries when SOPS_AGE_KEY_FILE points at that file, in
+ * file order), the target file's recipient list (scoped to the rule
+ * whose path_regex matches, when the parser can pin one, otherwise the
+ * union of all rules), and a truthful "is / is not in the list" verdict.
+ *
+ * Cures two live defects (w-2026-09-03-dave-011):
+ *   1. A file with multiple identities used to report only the first
+ *      `public key:` line. Now every identity in the key file is named.
+ *   2. The wording used to assert absence unconditionally, printing a
+ *      recipient list drawn from every creation_rule in the sops config.
+ *      When the caller's key was a recipient of ANOTHER rule the printed
+ *      list contradicted the assertion. Now the recipients are scoped
+ *      to the target's own rule, and the message states membership
+ *      truthfully: never claims absence when the list contains the key.
  */
 export function formatDecryptFailure(paths) {
   const target = paths.scope
     ? `scope "${paths.scope}"`
     : (paths.secretsFile ? `vault ${paths.secretsFile}` : 'vault');
-  let callerPub = null;
-  try {
-    callerPub = publicKeyFromKeyFile(paths.keyFile);
-  } catch { /* no key file, or unreadable: leave callerPub null */ }
-  const callerDesc = callerPub
-    ? `age key ${callerPub}`
-    : `age key at ${paths.keyFile}`;
-  const recipients = paths.sopsConfig ? readRecipientsFromSopsConfig(paths.sopsConfig) : [];
+
+  const callerPubs = paths.keyFile ? publicKeysFromKeyFile(paths.keyFile) : [];
+
+  // Prefer the recipient list of the specific target file's rule. Fall
+  // back to the union of every rule when the narrow parser cannot pin
+  // one; the wording checks membership either way, so falling back does
+  // not reintroduce the false-absence class the union alone caused.
+  let scopedRecipients = null;
+  if (paths.sopsConfig && paths.secretsFile) {
+    scopedRecipients = recipientsForTargetFile(paths.sopsConfig, paths.secretsFile);
+  }
+  const unionRecipients = paths.sopsConfig ? readRecipientsFromSopsConfig(paths.sopsConfig) : [];
+  const recipients = scopedRecipients ?? unionRecipients;
+  const recipientSet = new Set(recipients);
+  const matched = callerPubs.filter((k) => recipientSet.has(k));
+
+  const keyFileDesc = paths.keyFile ? ` (from ${paths.keyFile})` : '';
+  let callerDesc;
+  if (callerPubs.length === 0) {
+    callerDesc = paths.keyFile
+      ? `no age public key could be parsed from ${paths.keyFile}`
+      : 'no age key file path known';
+  } else if (callerPubs.length === 1) {
+    callerDesc = `age key ${callerPubs[0]}${keyFileDesc}`;
+  } else {
+    callerDesc = `age keys ${callerPubs.join(', ')}${keyFileDesc}`;
+  }
+
+  const recipientsLabel = scopedRecipients && paths.secretsFile
+    ? `recipients for ${basename(paths.secretsFile)} (from ${paths.sopsConfig})`
+    : `recipients (from ${paths.sopsConfig ?? '<no sops config>'})`;
   const recipientsDesc = recipients.length > 0
-    ? `recipients (from ${paths.sopsConfig}): ${recipients.join(', ')}`
+    ? `${recipientsLabel}: ${recipients.join(', ')}`
     : `recipients could not be read from ${paths.sopsConfig ?? '<no sops config>'}`;
-  return `Error: cannot decrypt ${target}: this host's ${callerDesc} is not in the recipient list; ${recipientsDesc}. Fix: add this host's public key to the scope's recipients, or run this verb from a host that already has decrypt access.`;
+
+  if (matched.length > 0) {
+    // Truthful branch: sops still refused even though the caller keys
+    // ARE listed as intended recipients. The two live causes are stale
+    // recipient stanzas in the encrypted store (needs `sops updatekeys`)
+    // and unreadable key file permissions.
+    const matchDesc = matched.length === 1
+      ? `${matched[0]} IS listed as a recipient`
+      : `${matched.join(', ')} ARE listed as recipients`;
+    return (
+      `Error: cannot decrypt ${target}: this host's ${matchDesc}, but sops still refused. ` +
+      'Common causes: the encrypted store predates this recipient stanza ' +
+      '(someone with decrypt access must run `sops updatekeys` on it), ' +
+      'or the key file permissions block sops from reading it. ' +
+      `${recipientsDesc}. Caller key file: ${callerDesc}.`
+    );
+  }
+  if (callerPubs.length === 0) {
+    return (
+      `Error: cannot decrypt ${target}: ${callerDesc}. ${recipientsDesc}. ` +
+      "Fix: restore your age key from backup, or run 'secrets init' to start a fresh vault."
+    );
+  }
+  return (
+    `Error: cannot decrypt ${target}: this host's ${callerDesc} is not in the recipient list; ` +
+    `${recipientsDesc}. ` +
+    "Fix: add this host's public key to the scope's recipients, or run this verb from a host that already has decrypt access."
+  );
 }
 
 /**

package/dist/engineering-pa-core/docs/tools/slice.md

@@ -21,7 +21,10 @@ Implemented: `generate`, `generate --dry-run`, `--help`.
 Bundled templates:
 
 - `dave-boot` — the original use case. Six-section operator-boot card aimed
-  at single-operator PA instances like Dave.
+  at single-operator PA instances like Dave. Sections: Operator basics,
+  Mission framing, Active relationships, Operational constraints, Tools at
+  your disposal, Live state. Post-generate lint enforces the 2026-09-03
+  contract (w-2026-07-15-012 / w-2026-09-04-dave-003).
 
 Custom templates are loaded with `--template <path>`.
 
@@ -59,14 +62,26 @@ Optional inputs:
    with `shell: false` — no shell interpolation, the inputs are safe even if
    they contain shell metacharacters.
 4. Validate the response against the required-headers contract (six
-   sections: Operator basics, Mission framing, Active projects, Active
-   relationships, Load-bearing rules right now, State of play). A response
+   sections: Operator basics, Mission framing, Active relationships,
+   Operational constraints, Tools at your disposal, Live state). A response
    missing any required header is treated as a generator failure (exit 2)
-   and no file is written.
+   and no file is written. The 2026-09-03 rewrite (w-2026-07-15-012)
+   retired the Active projects and Load-bearing rules sections: live boot
+   state is injected by the `boot-context` hook, and operational rules live
+   in `operator/knowledge/operator-interface/operational-constraints.md`.
 5. Validate the size against the 2 KB soft budget. Over-budget responses
-   produce a stderr warning but are written anyway — better to ship a 3 KB
-   slice than skip a regeneration.
-6. Write the response to the configured `--output` path. Parent directories
+   produce a stderr warning; the slice is still written when the byte
+   count sits inside the lint hard ceiling (`SIZE_LINT_HARD_BYTES`, 3000
+   B). Above that ceiling the post-generate lint refuses the write.
+6. Run the template-specific post-generate lint (dave-boot: names the
+   platform package `@stravica-ai/digital-operator-pa`, points at the
+   constraints doc, carries no `## Active projects` or `## In-flight work`
+   block, size within the hard ceiling). A lint failure refuses the write
+   with exit 2 so a defective regeneration cannot clobber the good slice
+   in place. Pass `--no-lint` to bypass. Custom templates loaded with
+   `--template <path>` have no template-specific checks and always
+   proceed to write. w-2026-09-04-dave-003.
+7. Write the response to the configured `--output` path. Parent directories
    are created if missing.
 
 #### Flags
@@ -80,6 +95,8 @@ Optional inputs:
                              this file. Default-off. See **Audit log** below.
 - `--dry-run`                Build the prompt and report; skip the claude
                              call and the file write.
+- `--no-lint`                Bypass the post-generate template-specific
+                             lint. See step 6 above.
 - `-h`, `--help`             Show usage.
 
 ### Exit codes
@@ -105,6 +122,9 @@ Status vocabulary (closed):
 - `noop-dry-run` — `--dry-run` path; no claude call, no file write.
 - `fail-claude` — claude exited non-zero (transport failure, exit 3).
 - `fail-validation` — claude returned content missing required headers (exit 2).
+- `fail-lint`: post-generate template lint refused the write (exit 2). The
+  regeneration was blocked from clobbering the good slice in place.
+  w-2026-09-04-dave-003.
 - `fail-prereq` — input loading failed (missing profile / observations / template, exit 2).
 - `fail-write` — writing the slice output file failed (permissions, ENOSPC, etc., exit 2).
 - `fail-usage` — early arg-validation failed (missing required option, exit 1).
@@ -134,8 +154,9 @@ A single markdown file at the `--output` path. Plain markdown, no
 front-matter, no JSON envelope. The PA's boot rule reads it the same way it
 reads the full profile.
 
-Soft target: under 2 KB / ~30 lines. Hard requirement: the six section
-headers must be present.
+Soft target: under 2 KB / ~30 lines. Hard requirements: the six section
+headers must be present, and (for the bundled `dave-boot` template) the
+post-generate lint contract in step 6.
 
 ## Design notes
 

package/dist/engineering-pa-core/src/slice/cli.mjs

@@ -33,6 +33,16 @@ Options for "generate":
                             slice runs on a schedule, point this at a
                             per-task runs.jsonl. Optional.
   --dry-run                 Build the prompt and report; skip claude call + write.
+  --no-lint                 Bypass the post-generate template-specific lint.
+                            The lint refuses to write a slice that fails the
+                            template's contract checks (dave-boot: names the
+                            platform package, points at the constraints doc,
+                            no baked in-flight state, size within ceiling).
+                            The scheduled nightly leaves this OFF so a
+                            defective regeneration cannot clobber the good
+                            slice; hand-invocations may pass it when the
+                            checks are known to be wrong for the current
+                            contract.
   -h, --help                Show this help.
 
 Exit codes:
@@ -89,6 +99,7 @@ async function route(argv, { stderr, stdout, exit }) {
         template: { type: 'string' },
         'runs-log': { type: 'string' },
         'dry-run': { type: 'boolean', default: false },
+        'no-lint': { type: 'boolean', default: false },
         help: { type: 'boolean', short: 'h', default: false },
       },
       strict: true,
@@ -126,6 +137,7 @@ async function route(argv, { stderr, stdout, exit }) {
       outputPath: values.output,
       runsLog: values['runs-log'],
       dryRun: values['dry-run'],
+      noLint: values['no-lint'],
       runner: defaultRunner,
       stderr,
     });

package/dist/engineering-pa-core/src/slice/prompts/dave-boot.md

@@ -1,33 +1,32 @@
-You are operating as a compression assistant. Your job is to produce a compact "boot slice" of the operator's profile — a short markdown document that loads into the PA's context at every session start, in place of the full profile.
+You are operating as a compression assistant. Your job is to produce a compact "boot slice" of the operator's profile: a short markdown document that loads into the PA's context at every session start, in place of the full profile.
 
 The full profile is the source of truth. This slice is a fresh snapshot, regenerated periodically. Stale content in the slice is acceptable for ~24 hours.
 
 ## What the slice is for
 
-When the PA boots, it needs to know — in roughly 1–2 KB of context — *who it is working for*. Not every preference, not every historical decision, not every technical opinion. Just enough that:
+When the PA boots, it needs to know, in roughly 1 to 2 KB of context, *who it is working for*. Not every preference, not every historical decision, not every technical opinion. Just enough that:
 
 - It addresses the operator correctly (name, register, tone).
 - It knows the operator's mission framing this year.
-- It knows what's in flight right now (active projects, active relationships).
+- It knows the standing relationships that carry across sessions.
 - It is aware of the tools and capabilities already built and available.
-- It avoids the highest-cost mistakes (5–10 most load-bearing recent corrections / rules).
-- It can read the rest of the profile or knowledge base when it needs detail.
+- It picks up operational constraints from the canonical constraints doc, not from a stale slice copy.
 
-This is a navigation card, not the territory. **Prefer pointers to canonical sources over baked-in content** that will go stale between regenerations.
+This is a navigation card, not the territory. **Prefer pointers to canonical sources over baked-in content** that will go stale between regenerations. Live boot state (active projects, in-flight work) is injected by the `boot-context` hook at session start, so the slice must NOT carry that state.
 
 ## Inputs you have
 
 You are given:
 
-1. **The full operator profile** (`profile.md`) — the source of truth, ~18 KB.
-2. **Recent corrections / load-bearing rules** (optional, `learned-rules.md`) — ~50 KB of operational rules accumulated from corrections.
-3. **Recent observations** (optional) — a concatenated dump of raw observation files filed in the last 2–4 weeks, useful for "what's been on his mind lately" but not authoritative.
+1. **The full operator profile** (`profile.md`): the source of truth, ~18 KB.
+2. **Recent corrections / load-bearing rules** (optional, `learned-rules.md`): ~50 KB of operational rules accumulated from corrections. Use only to inform vocabulary and register; do NOT bake rules into the slice.
+3. **Recent observations** (optional): a concatenated dump of raw observation files filed in the last 2 to 4 weeks, useful for "what's been on his mind lately" but not authoritative.
 
-Treat the profile as authoritative. Treat learned-rules as second-tier authoritative (they ARE rules). Treat observations as raw signal — synthesise, do not quote.
+Treat the profile as authoritative. Treat learned-rules as second-tier authoritative (they ARE rules, but they live in their own file: do not re-state them here). Treat observations as raw signal: synthesise, do not quote.
 
 ## Output structure
 
-Produce a markdown document with exactly these seven sections, in this order:
+Produce a markdown document with exactly these six sections, in this order:
 
 ```
 # Operator Boot Slice -- <Operator Name>
@@ -35,56 +34,59 @@ Produce a markdown document with exactly these seven sections, in this order:
 _Generated <ISO timestamp>. Refreshed periodically. Source of truth: operator/profile/profile.md._
 
 ## Operator basics
-<3-5 bullets: name, what they go by, communication register, tone preferences, sensitivities>
+<3 to 5 bullets: name, what they go by, communication register, tone preferences, sensitivities>
 
 ## Mission framing
-<1-2 lines: the north-star / what we're building toward this year>
-
-## Active projects
-<3-6 bullets, one line each: project name -- one-line status>
+<1 to 2 lines: the north-star and what the operator is building toward this year. Name the PA platform's ship-vehicle plainly. The platform ships as `@stravica-ai/digital-operator-pa` on npm; if the profile confirms this, say so.>
 
 ## Active relationships
-<2-4 bullets, one line each: who -- relationship context>
+<2 to 4 bullets, one line each: who -- relationship context. Standing relationships only, not one-off collaborations.>
+
+## Operational constraints (session-load)
+
+Read `operator/knowledge/operator-interface/operational-constraints.md` on every boot. That doc carries network, infrastructure, tooling, estate and voice constraints and standing corrections. It is the one place these live; anything you find restated in this slice or in `profile.md` is a defect, escalate it under the routing rule in `operator/knowledge/knowledge-memory/share-scope-routing.md`.
 
 ## Tools at your disposal
-<2-3 lines: a one-line summary of the HQ-built operator-extension tools you have available (look for evidence of these in the inputs — names like wsd-ingest, dispatch, svc, monitoring, scheduled cron tasks, etc.), followed by a pointer line to the canonical list:>
-For the canonical inventory of operator-built tools and scheduled tasks, read `operator/knowledge/systems/operator-tools.md`.
 
-## Load-bearing rules right now
-<5-10 bullets, one line each: most-cited or most-recent operational rules from learned-rules and the profile preferences section. Pick rules whose violation would be most costly>
+<2 to 3 lines: a one-line summary of the platform bins (via `pnpm exec <bin>`; the platform ships as `@stravica-ai/digital-operator-pa`) and the HQ operator-extension tools available, followed by a pointer line:>
+For the current tool surface each session, discover via `ls operator/extensions/tools/` and `pnpm exec pa --help`; never rely on memory.
+
+## Live state -- fetch on boot
 
-## Live state — fetch on boot
-For current project and work-item state, run: `pnpm exec desk overview`.
-Do not bake state into this slice — it will be wrong by the time it is read.
+For current projects and in-flight work items: `pnpm exec desk overview`.
+For the last session's boundary notes: `agents/dave/next-session.md`.
+For recent dispatches: tail `agents/dave/spawn-log.json`.
+The `boot-context` hook injects a live `workState` block on session start; trust that first, hunt files only if the hook did not fire.
+Do not bake state into this slice, it will be wrong by the time it is read.
 ```
 
-The last section is a **fixed instruction**, not generated content. Reproduce it verbatim. The whole point is to send the PA to the live tool for any state question rather than relying on a frozen snapshot.
+The **Operational constraints** section and the **Live state** section are **fixed instructions**, not generated content. Reproduce them verbatim. The point is to send the PA to the canonical constraints doc for any operational rule, and to the live tools for any state question, rather than relying on a frozen snapshot.
 
 ## Budget
 
-**Soft target: under 2 KB total output.** Aim for ~1.2–1.8 KB. If you can't fit a section in the budget, prefer fewer items over shorter items — better to give 3 sharp project lines than 6 mushy ones. Over-budget is warned but not blocked; under-information is more costly.
+**Soft target: under 2 KB total output.** Aim for ~1.2 to 1.8 KB. If a section will not fit in the budget, prefer fewer items over shorter items: better to give 3 sharp lines than 6 mushy ones. Over-budget is warned; under-information is more costly.
 
 ## Style
 
 - No emojis (the operator has a strict no-emoji rule for persisted artefacts).
-- No em-dashes — use double-hyphens (`--`) instead.
+- No em-dashes anywhere. Use a comma, a full stop, or a colon. The double-hyphen `--` in the file title and the "Live state -- fetch on boot" heading is intentional and must be reproduced verbatim.
 - Use the operator's own vocabulary where you can pull it cleanly from the profile.
-- Don't editorialise. State, don't sell.
+- Do not editorialise. State, do not sell.
 - "Operator" not "user". "PA" or the PA's name, not "the assistant".
 
 ## What NOT to include
 
-- Technical opinions (the full Technical Opinions section of profile.md).
+- Technical opinions (the full Technical Opinions section of `profile.md`).
 - Historical decision patterns.
-- Communication-style examples that aren't load-bearing.
+- A "Load-bearing rules" or "Active projects" or "In-flight work" block: the constraints doc and the `boot-context` hook cover those; a baked copy here goes stale within hours.
+- Communication-style examples that are not load-bearing.
 - Anything the PA can look up at the moment it needs it (this is what the pointers are for).
-- A baked snapshot of project state — the Live-state section's pointer covers that.
 
-The test for "should this be in the slice": *if this is wrong or missing, will the PA make a costly mistake in its first 5 messages?* If yes, include it. If no, leave it out.
+The test for "should this be in the slice": *if this is wrong or missing, will the PA make a costly mistake in its first 5 messages, AND is it something the constraints doc plus the boot-context hook cannot cover?* If yes to both, include it. If no, leave it out.
 
 ## Now produce the slice
 
-The inputs follow below. Read them, then produce the slice. Output ONLY the slice markdown — no preamble, no postscript, no explanation. Your entire response is what gets written to disk.
+The inputs follow below. Read them, then produce the slice. Output ONLY the slice markdown: no preamble, no postscript, no explanation. Your entire response is what gets written to disk.
 
 ---