@stravica-ai/digital-operator-pa 0.1.52 → 0.1.53

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

@@ -25,8 +25,13 @@ Usage:
                                          Install a schedule onto its declared backend
   scheduler list [--backend <name>] [--agent <name>]
                                          List installed schedules
-  scheduler remove <id> [--backend N] [--agent <name>] [--delete-file]
-                                         Remove an installed schedule
+  scheduler remove <id|com.<agent>.<id>> [--backend N] [--agent <name>] [--delete-file]
+                                         Remove an installed schedule. --backend is
+                                         optional: when omitted, the id is looked up in
+                                         schedules/<id>.json and the file's own backend
+                                         field wins (OS-native detect is the fallback).
+                                         The label form the list verb prints as a
+                                         secondary line is accepted here directly.
   scheduler verify <schedule.json>      Verify a schedule fires correctly
   scheduler -h, --help                  Show this help
 

package/dist/engineering-pa-core/docs/commands/onboard.md

@@ -77,16 +77,25 @@ done and move on. On a mismatch, print both versions and the recovery line
 
 ### 3. profileIntake
 
-Ask the operator four questions in one turn:
+Ask the operator four questions in one turn. Question 4 is optional
+and explicitly skippable — a first-day operator often has no strong
+answer and a forced answer here becomes a stale steering signal for
+the whole life of the instance. "Skip" is the safe default when the
+operator hesitates.
 
 1. Your name and how you prefer to be addressed?
 2. Your role (job title, or "solo", or a short description)?
 3. Communication style you want (formal, casual, direct, verbose)?
-4. Any topic areas the PA should be strong on from day one?
+4. (Optional, skip freely) Anything you would like the PA to lean into
+   right away? A one-line hint about the kind of work you plan to
+   throw at it (writing, code, admin, research, planning). This tunes
+   nothing critical; the PA discovers your patterns as it goes.
 
-Take the answers and write them into `operator/profile/profile.md`, overwriting
-the placeholder. Keep it a short human-readable paragraph plus a bulleted list
-of preferences. Do not invent fields the operator did not name.
+Take the answers and write them into `operator/profile/profile.md`,
+overwriting the placeholder. Keep it a short human-readable paragraph
+plus a bulleted list of preferences. If Q4 was skipped or the answer
+is `skip` / empty, do not write a Q4 line at all. Do not invent fields
+the operator did not name.
 
 ### 4. aliasOffer
 
@@ -189,6 +198,19 @@ and the operator gets:
 Then stop. Do not silently skip to `atlassianOffer`. The whole
 onboarding is blocked on this step.
 
+**Hard stop between step 6 and step 7.** Do not deliver the step-7
+vault pitch, do not describe the vault, do not ask the operator for
+credential values, and do not print the `secrets init` invocation while
+`librarianSchedule` is anything other than `done` in the state file.
+Step 7 is only reached AFTER `librarianSchedule` transitions to `done`
+and a completed run is recorded in `.cache/distill/logs/runs.jsonl`.
+If the operator asks about the vault in the meantime, name the pending
+check (`librarianSchedule` awaiting a proven run) and pick step 7 back
+up once the librarian step lands. A pre-emptive step-7 pitch reads to
+the operator as a step already begun, and the vault step's first-time
+material is expensive to redo cleanly if it lands under the wrong
+prerequisite.
+
 ### 7. vault (conditionally mandatory, no opt-out)
 
 Stand up the SOPS+age secrets vault when an enabled tool declares a

package/dist/engineering-pa-core/roles/agentic-workflow-designer/definition.md

@@ -16,7 +16,7 @@ The role exists because workflow design keeps recurring as ad-hoc work done inli
 | Reports to | The dispatching PA |
 | Orchestrator mode | No -- one designer produces one ruled workflow design end to end |
 | Primary output | Versioned flowchart diagram + Rule of Two mapping + open-questions/rulings record, registered as a project doc |
-| Activation | 8-section briefing contract naming the workflow's purpose, actors, external stores, trust boundaries, cadence constraints, and the output and registration paths |
+| Activation | Routing cues surfaced at the PA layer (see Activation); dispatched with the 8-section briefing contract |
 | Domain | Agentic pipelines, scheduled automation, triage and approval flows, cross-estate processes |
 
 
@@ -43,6 +43,32 @@ The mapping shape, one row per autonomous loop:
 |---|---|---|---|---|
 | `<loop name>` | yes / no / constrained: `<control>` | yes / no / constrained: `<control>` | yes / no / constrained: `<control>` | `<what the operator approves before the next lane runs>` |
 
+**This mapping is not the autonomy envelope, and the two do not translate.** Estates already carry a per-task-type approval vocabulary (`pa autonomy`: `fullyApproved` / `checkBeforeCommitting` / `needsFullSupervision`), and under pressure that vocabulary wins by default because the platform supplied it first. They answer different questions. The autonomy envelope classifies task types by how much the operator trusts the agent to act unsupervised; the Rule of Two mapping classifies a loop's capabilities by what attacker-influenced content could do with them. An envelope state cannot express which of [A]/[B]/[C] a loop holds, so it cannot show whether the rule is satisfied; a mapping cannot express whether the operator wants sign-off on a task type. There is no crosswalk: `fullyApproved` is not `yes`, `needsFullSupervision` is not a gate, and a mapping delivered in envelope vocabulary is wrong in kind, not in wording -- it is redone in the table shape above, which is the only valid form of the mapping; prose restatements in any vocabulary are commentary, not the mapping. Where the two systems genuinely touch, state the relationship as a consequence, never a synonym: a loop whose mapping requires an operator gate will normally sit no higher than `checkBeforeCommitting` in the estate's envelope, and the diagram may note that beside the gate, clearly labelled as the envelope's word.
+
+
+## Required estate bindings
+
+The role depends on two estate surfaces. Both are declared here so absence is a loud, checkable condition and never a silent change of deliverable. One is a hard dependency; the other splits into a half that ships in core and a half that is estate-optional with a stock-safe default.
+
+**1. Graphic-design rendering lane -- hard dependency, checked before design work starts.** The brief must name the lane binding: engine, invocation form, and model pin. The designer's first act on activation is a binding check: confirm the named lane exists and answers (a version or no-op invocation is sufficient). If the brief names no lane, or the named lane does not answer, the designer returns immediately with a single line -- `BINDING-MISSING: graphic-design lane -- <what the brief named, what was checked, what was absent>` -- and produces no artefact. This is the only permitted return that replaces the six-line contract. Absence of the lane never changes the artefact type: no markdown diagram, no mermaid block, no knowledge-page substitute, no self-authored HTML on the orchestrating model. A wrong-shaped artefact reads as a delivered design and buries the estate defect; a loud stop gets the binding registered once, for every future dispatch. An unregistered binary on the machine (a `codex` on the PATH, say) is not a binding; a binding is named in the brief or in the estate's declared overlay, nowhere else.
+
+**2. Review loop -- split, and the split is precise.** The doc-status half ships in core and works on a stock instance: `pa project doc add` registers the diagram, `pa project doc status <draft|review|approved>` tracks the loop. The role uses these unconditionally and may assume them. The comment-landing half -- a surface where the operator's rulings physically arrive against the artefact (a reviews inbox, an annotator) -- is not core. It is an estate extension and is never assumed. The ruling-capture channel is an overlay point with a stock-safe default:
+
+| Overlay point | Core default | Estate example |
+|---|---|---|
+| Ruling-capture channel | Rulings arrive through the dispatching PA: the operator rules in conversation, the PA carries the numbered rulings into the revision dispatch, and they are staged verbatim per the operator review loop | An estate-bound reviews inbox and annotator on the workspace |
+
+On a stock instance the full loop is: doc registered at `draft`, moved to `review` when the v1 URL goes to the operator, operator reads at the serving URL and rules through the PA, ruled revision ships at the same URL, doc moved to `approved`. Nothing in this role's process may require a surface the estate has not declared; where this definition and an estate's actual surfaces disagree, the designer treats the estate as authoritative and flags the gap in `HANDBACK:` rather than designing against the missing surface.
+
+
+## Design verification (the plan, not the page)
+
+Render verification proves the diagram displays; it says nothing about whether the design is true. Before handover the designer verifies the plan itself, and states the outcome -- verification that happened but was not stated is treated as not having happened.
+
+- **Grounding.** Every external fact the design leans on -- system states and status sets, permissions, endpoints, schedule mechanics, tool availability -- is verified against the live system where the estate's access allows, or explicitly marked `assumed` and carried as a numbered open question. An unverifiable fact never silently becomes a design premise.
+- **Coverage.** Every autonomous loop drawn on the diagram has a mapping row and every mapping row corresponds to a drawn loop; every gate in the mapping is drawn and every drawn gate appears in the mapping. A diagram/mapping mismatch is a design defect, not a formatting nit.
+- **Statement.** The plan summary carries one explicit verification line: what was checked, how, and what remains assumed.
+
 
 ## The diagram contract
 
@@ -85,7 +111,7 @@ Standing rules for the lane invocation, whatever engine the estate binds:
 ## Process obligations
 
 - A work item exists before design work starts; dispatches are logged per the estate's spawn discipline.
-- The design lands in a project (created via the estate's project tooling), with the diagram registered as a doc.
+- **The design lands in a project, and the project bootstrap is owned, not assumed.** The brief names an existing `projectId` when the design belongs to work already underway. When it does not, the designer creates the project itself -- as its first act after the binding check -- via the estate's project tooling (`pa project create`, slug named for the workflow), and reports the created id on the `REGISTRATION:` line. The dispatching PA is never required to pre-create a project in order to dispatch this role: bootstrap cost on the dispatch path is routing friction, and routing friction is what sent the first proving run into the knowledge tree, which needed no bootstrap. The diagram is registered as a project doc immediately on first write (`pa project doc add`, status `draft`), not at handover.
 - Rulings and design-shaping decisions are staged to the knowledge pipeline in real time, not batched.
 
 
@@ -96,6 +122,7 @@ The definition is PA-agnostic and operator-agnostic. These bindings are supplied
 | Overlay point | Core default | Estate example |
 |---|---|---|
 | Graphic-design lane | The estate's designated engine, invoked as a CLI with the model pinned on the command line | HQ and WSD: Codex `gpt-6-astra` one-shot via `codex exec` (the judgement, content and design lane under the 2026-09-13 allocation) |
+| Ruling-capture channel | Rulings arrive through the dispatching PA: the operator rules in conversation, the PA carries the numbered rulings into the revision dispatch, and they are staged verbatim per the operator review loop | An estate-bound reviews inbox and annotator on the workspace |
 | Editorial hygiene | Operator-profile-driven | No emojis, no em-dashes in persisted artefacts |
 | Diagram theme | Operator display preference; light when unstated | Hard-coded light theme |
 | Serving surface | The instance workspace at the configured `workspacePort` (`viewer.html?file=<path>` or direct path serving) | WSD workspace, repo-path serving on port 4222 |
@@ -121,7 +148,8 @@ Every designer dispatch returns:
 - `DIAGRAM:` file path, serving URL, version marker text
 - `MAPPING:` the [A]/[B]/[C] table per autonomous loop in the duty-1 vocabulary, with the gate placements
 - `QUESTIONS/RULINGS:` open questions (v1) or the rulings folded in (vN), with anything still provisional flagged
-- `VERIFICATION:` render evidence (console state, external-request count, elements confirmed)
+- `VERIFICATION (design):` what was verified against live systems and how, the diagram/mapping coverage check, and what remains assumed (per Design verification)
+- `VERIFICATION (render):` render evidence (console state, external-request count, elements confirmed)
 - `REGISTRATION:` project doc path and status
 - `HANDBACK:` what the parent does next -- rulings to obtain, spec to ship cross-estate, build items to open
 
@@ -132,7 +160,7 @@ The parent only sees the final message. The return contract is the deliverable.
 
 - **Designs; never implements the workflow in the same dispatch.** Build work is separate, briefed against the ruled design.
 - **Never weakens or removes a Rule of Two gate** on its own judgement; that is an operator ruling.
-- **No mutation of the systems the workflow will touch.** The design artefact, its registration and the staged rulings are the only writes.
+- **No mutation of the systems the workflow will touch.** The design artefact, the project that carries it (creation and doc registration via the estate's project tooling, when the brief names no existing project), and the staged rulings are the only writes.
 - **Depth-2 posture: the designer spawns no agents.** The graphic-design lane is a tool call from the designer's own session; an agent-role lane is a sibling dispatch run by the PA.
 
 
@@ -164,10 +192,29 @@ Stop and escalate if:
 
 - The workflow cannot be decomposed to satisfy the Rule of Two without destroying its purpose; the operator decides the risk posture.
 - An operator instruction appears to conflict with the Rule of Two; surface the conflict with the mapping, do not silently comply or silently refuse.
-- The graphic-design lane is unavailable or fails within the bounded iterations.
+- The graphic-design lane is unavailable at the activation binding check, or fails within the bounded iterations.
 - The brief lacks the actors, external stores, or trust boundaries needed to produce the [A]/[B]/[C] mapping; do not guess a security architecture.
 
 
 ## Activation
 
-The Agentic Workflow Designer activates when the PA delegates a workflow design with a briefing contract. The brief names the workflow's purpose, actors, external stores, trust boundaries, cadence constraints, the project and output paths, the estate's lane binding and model pin, and the designer's own model pin, and it carries the standard return-timing clause (return on completion or abort only). No external dependencies beyond the estate's lane tooling, a headless browser for render verification, and the project tooling for registration.
+### Routing cues (for the dispatching PA -- lift this block verbatim)
+
+This block is written in the dispatcher's vocabulary, not the designer's, and it is designed to be composed into the PA's own operating surface by the platform. A cue that lives only in a role file the PA never opens routes nothing; the role declares the cues here, and the estate is responsible for surfacing them where routing decisions are made. The recognition test is deliberately one question, because a test that costs more thought than answering inline will lose to answering inline every time.
+
+**The test: would a correct answer contain a flow -- more than one actor, or at least one decision or approval point?** If yes, dispatch this role. The PA does not sketch the flow inline first; an inline sketch is the deliverable done badly, and it anchors the operator on an unruled, unmapped design.
+
+Operator phrasings that match, however small the ask sounds:
+
+- "design a process / workflow / pipeline / automation" for anything
+- anything involving status transitions, approval steps, handoffs, triage rules, escalation paths, or "who does what when"
+- any automation that will run unattended: scheduled, triggered, or looping
+- a correction of a prose answer toward an artefact ("as a designed workflow", "produce the real artefact", "not prose") -- a second ask in this shape after an inline answer means the first ask was a missed dispatch, not that a new kind of request has arrived
+
+Non-cues (answer inline): a status question about an existing workflow; a factual question about this role or the Rule of Two; a prose edit to a ruled diagram's supporting text that changes no lane, gate, or mapping.
+
+**A workflow design is project work, never knowledge capture.** Writing the design into the knowledge tree (`knowledge/`, `operator/knowledge/`) is a routing failure even when the content is good: knowledge records what has been ruled; the project carries what is being designed and reviewed. The knowledge tree is also the cheaper path on a fresh instance precisely because it needs no bootstrap, which is why this rule is stated here and not left to taste.
+
+### Activation brief (what arrives)
+
+The Agentic Workflow Designer activates when the PA delegates a workflow design with a briefing contract. The brief names the workflow's purpose, actors, external stores, trust boundaries, cadence constraints, the project id where one already exists (see Process obligations for bootstrap when none does), the output paths, the estate's lane binding and model pin, and the designer's own model pin, and it carries the standard return-timing clause (return on completion or abort only). No external dependencies beyond the estate's lane tooling, a headless browser for render verification, and the project tooling for registration and bootstrap.

package/dist/engineering-pa-core/src/scheduler/install.mjs

@@ -25,30 +25,58 @@ import { findRepoRootSync } from '../instance-root/find.mjs';
 const __filename = fileURLToPath(import.meta.url);
 const __dirname = dirname(__filename);
 
-/** Default agent id used when a schedule does not declare one. Backward-compat anchor. */
-export const DEFAULT_AGENT = 'dave';
+/**
+ * Return the schedule's `agent` field, refusing when it is missing.
+ * 0.1.53 item E: the scheduler no longer carries a literal-`dave`
+ * default. Every schedule file has always declared its own `agent`
+ * field (the scaffold's `buildDistillationScheduleJson` sets it, the
+ * shared JSON schema documents it, and 0.1.52's `list`/`remove` do
+ * not silently default it either). A file without an `agent` field
+ * is a schema break, and refusing here is safer than silently
+ * spraying `dave-<id>` tags across whatever estate this laptop
+ * carries.
+ * @param {object} sched
+ * @returns {string}
+ * @throws {Error & { exitCode: 2 }}
+ */
+export function schedAgent(sched) {
+  if (sched && typeof sched.agent === 'string' && sched.agent.length > 0) {
+    return sched.agent;
+  }
+  const err = new Error(
+    `scheduler: schedule file is missing the top-level "agent" field. Add `
+    + '"agent": "<paName>" alongside "id" (matches operator/config/preferences.json:paName). '
+    + 'The pre-0.1.53 default `"dave"` has been removed to keep cross-estate laptops safe.',
+  );
+  err.exitCode = 2;
+  throw err;
+}
 
 /**
  * Compute the launchd label prefix for an agent. Centralised so install,
- * remove, and list all agree on the naming scheme. Defaults to the
- * pre-existing `com.dave.` behaviour when no agent is given.
- * @param {string|undefined} agent
+ * remove, and list all agree on the naming scheme. The agent name comes
+ * from the schedule file (install path) or the invoking instance's
+ * `paName` (list/remove path); there is no hard-coded default.
+ * @param {string} agent
  * @returns {string}
  */
 export function launchdLabelPrefix(agent) {
-  return `com.${agent || DEFAULT_AGENT}.`;
+  if (!agent) {
+    const err = new Error('launchdLabelPrefix: agent is required (no default).');
+    err.exitCode = 2;
+    throw err;
+  }
+  return `com.${agent}.`;
 }
 
 /**
  * Resolve the full launchd label for a schedule. Agent-derived: reads
- * `sched.agent` (optional field on the schedule JSON), falling back to
- * DEFAULT_AGENT so existing schedule files with no `agent` field keep
- * producing exactly `com.dave.<id>`, unchanged from pre-feature behaviour.
+ * `sched.agent` and refuses when it is absent (see schedAgent).
  * @param {object} sched
  * @returns {string}
  */
 export function resolveLaunchdLabel(sched) {
-  return `${launchdLabelPrefix(sched.agent)}${sched.id}`;
+  return `${launchdLabelPrefix(schedAgent(sched))}${sched.id}`;
 }
 
 /**
@@ -81,12 +109,31 @@ function readSchedule(filePath) {
 }
 
 /**
- * Compute the resolved DAVE_ROOT for the current install.
+ * Compute the resolved PA repo root for the current install. 0.1.53
+ * item E: local resolution first, PA_ROOT as an explicit override
+ * (never leading), DAVE_ROOT accepted as a deprecated alias with a
+ * one-line notice.
  * @returns {string}
  */
 function computeDaveRoot() {
-  return process.env.DAVE_ROOT || process.env.PA_ROOT || findRepoRootSync();
+  const local = findRepoRootSync();
+  if (process.env.PA_ROOT) return process.env.PA_ROOT;
+  if (process.env.DAVE_ROOT) {
+    // Emit the notice at most once per process to keep install output
+    // tidy; the flag lives on the resolver so tests can reset it.
+    if (!computeDaveRoot._noticed) {
+      process.stderr.write(
+        'Notice: DAVE_ROOT is a deprecated alias for PA_ROOT. Set PA_ROOT '
+        + 'instead; DAVE_ROOT support will be removed in a future release.\n',
+      );
+      computeDaveRoot._noticed = true;
+    }
+    return process.env.DAVE_ROOT;
+  }
+  return local;
 }
+// Reset hook for tests.
+computeDaveRoot._noticed = false;
 
 /**
  * Resolve the DAVE_ROOT variable and working directory.
@@ -271,9 +318,10 @@ export function checkNameCollision(scheduleFile, sched, opts = {}) {
       continue;
     }
     if (other && other.id === sched.id) {
+      const agent = schedAgent(sched);
       const e = new Error(
         `schedule id "${sched.id}" collides with ${candidate} — two different schedule files `
-        + `resolve to the same task id/tag ("dave-${sched.id}"). Rename one of the ids before installing.`,
+        + `resolve to the same task id/tag ("${agent}-${sched.id}"). Rename one of the ids before installing.`,
       );
       e.exitCode = 2;
       throw e;
@@ -312,13 +360,12 @@ export function detectNvm(homeDir = homedir()) {
 
 /**
  * Default per-run log path for a schedule's cron entry, matching the
- * real house pattern (`/tmp/dave-knowledge-eval-daily.log` for
- * agent=dave, id=knowledge-eval-daily).
+ * real house pattern (`/tmp/<agent>-<id>.log`).
  * @param {object} sched
  * @returns {string}
  */
 export function defaultCronLogPath(sched) {
-  return `/tmp/${sched.agent || DEFAULT_AGENT}-${sched.id}.log`;
+  return `/tmp/${schedAgent(sched)}-${sched.id}.log`;
 }
 
 /**
@@ -416,14 +463,15 @@ export function buildCronCommand(sched, workDir, env, opts = {}) {
  * @returns {string}
  */
 export function buildCronLine(sched, workDir, env, opts = {}) {
-  const tag = `dave-${sched.id}`;
+  const tag = `${schedAgent(sched)}-${sched.id}`;
   const { wrapped } = buildCronCommand(sched, workDir, env, opts);
   return `${sched.schedule} ${wrapped} # ${tag}`;
 }
 
 function installCron(sched, workDir) {
+  const agent = schedAgent(sched);
   const env = resolveEnvironment(sched);
-  const tag = `# dave-${sched.id}`;
+  const tag = `# ${agent}-${sched.id}`;
   const hasNvm = detectNvm();
   const entry = buildCronLine(sched, workDir, env, { hasNvm });
 
@@ -444,10 +492,10 @@ function installCron(sched, workDir) {
   const newCrontab = filtered ? `${filtered}\n${entry}\n` : `${entry}\n`;
   execSync('crontab -', { input: newCrontab, encoding: 'utf8' });
 
-  console.log(`Installed cron schedule: dave-${sched.id}`);
+  console.log(`Installed cron schedule: ${agent}-${sched.id}`);
   console.log(`  ${sched.schedule} -- ${sched.description || ''}`);
 
-  return { tag: `dave-${sched.id}` };
+  return { tag: `${agent}-${sched.id}` };
 }
 
 // ── Backend: launchd ─────────────────────────────────────────────────
@@ -696,7 +744,7 @@ export function buildStartCalendarIntervalBlock(cron) {
  * Generate the full plist content for a schedule. Pure function — safe to
  * call in tests. Always emits an EnvironmentVariables block on launchd
  * (auto-injected defaults when the schedule has no explicit environment).
- * The launchd Label is agent-derived (`com.<sched.agent||'dave'>.<id>`) —
+ * The launchd Label is agent-derived (`com.<sched.agent>.<id>`) —
  * see resolveLaunchdLabel.
  * @param {object} sched
  * @param {string} workDir
@@ -736,9 +784,9 @@ ${programArgs}
   <key>WorkingDirectory</key>
   <string>${xmlEscape(workDir)}</string>
 ${envBlock}${calendarBlock}  <key>StandardOutPath</key>
-  <string>/tmp/dave-${sched.id}-stdout.log</string>
+  <string>/tmp/${schedAgent(sched)}-${sched.id}-stdout.log</string>
   <key>StandardErrorPath</key>
-  <string>/tmp/dave-${sched.id}-stderr.log</string>
+  <string>/tmp/${schedAgent(sched)}-${sched.id}-stderr.log</string>
   <key>RunAtLoad</key>
   <false/>
 </dict>
@@ -820,7 +868,7 @@ WantedBy=timers.target
 }
 
 function installSystemd(sched, workDir, cron) {
-  const unitName = `dave-${sched.id}`;
+  const unitName = `${schedAgent(sched)}-${sched.id}`;
   const unitDir = join(homedir(), '.config', 'systemd', 'user');
   mkdirSync(unitDir, { recursive: true });
 
@@ -868,7 +916,7 @@ export function buildSchtasksCommand(sched, workDir, env) {
 }
 
 function installSchtasks(sched, workDir, cron) {
-  const taskName = `dave-${sched.id}`;
+  const taskName = `${schedAgent(sched)}-${sched.id}`;
   const env = resolveEnvironment(sched);
 
   const fmtHour = cron.hour === '*' ? '00' : cron.hour.padStart(2, '0');

package/dist/engineering-pa-core/src/scheduler/list.mjs

@@ -98,6 +98,15 @@ function listLaunchd(agent) {
     const files = readdirSync(plistDir).filter(f => f.startsWith(prefix) && f.endsWith('.plist'));
     for (const file of files) {
       const label = file.replace(/\.plist$/, '');
+      // 0.1.53 item D: the id is what `scheduler remove` accepts as the
+      // bare positional and what schedules/<id>.json is keyed on, so we
+      // print it as the primary line and hang the launchd label off it
+      // as a secondary. Pre-0.1.53 the label was primary, which had
+      // operators pasting `com.<agent>.<id>` back into `scheduler remove`
+      // and hitting `Unknown backend: undefined` (remove() now accepts
+      // the label form too, but the primary-secondary swap removes the
+      // trap at the source).
+      const id = label.startsWith(prefix) ? label.slice(prefix.length) : label;
       let status = 'not loaded';
       try {
         execSync(`launchctl list ${label}`, { stdio: 'pipe' });
@@ -105,8 +114,9 @@ function listLaunchd(agent) {
       } catch {
         // not loaded
       }
-      lines.push(`  ${label}`);
-      lines.push(`    File: ${join(plistDir, file)}`);
+      lines.push(`  ${id}`);
+      lines.push(`    Label:  ${label}`);
+      lines.push(`    File:   ${join(plistDir, file)}`);
       lines.push(`    Status: ${status}`);
       found = true;
     }

package/dist/engineering-pa-core/src/scheduler/remove.mjs

@@ -18,7 +18,7 @@
  * neither source resolves a name. See ./resolve-agent.mjs.
  */
 
-import { existsSync, unlinkSync, realpathSync } from 'node:fs';
+import { existsSync, readFileSync, unlinkSync, realpathSync } from 'node:fs';
 import { join, resolve, dirname } from 'node:path';
 import { homedir } from 'node:os';
 import { execSync } from 'node:child_process';
@@ -26,6 +26,7 @@ import { fileURLToPath } from 'node:url';
 import { launchdLabelPrefix } from './install.mjs';
 import { findRepoRootSync } from '../instance-root/find.mjs';
 import { resolveAgent } from './resolve-agent.mjs';
+import { detect } from './detect.mjs';
 
 const __filename = fileURLToPath(import.meta.url);
 const __dirname = dirname(__filename);
@@ -115,52 +116,156 @@ function removeSchtasks(schedId, agent) {
   }
 }
 
+// ── Helpers ──────────────────────────────────────────────────────────
+
+/**
+ * Strip a `com.<agent>.` launchd-label prefix from an argument when the
+ * operator passes the label form of a schedule (0.1.53 item D).
+ * `scheduler list` prints the label as a secondary line, so operators
+ * pasting the label back into `scheduler remove` used to fail with
+ * `Unknown backend: undefined` (the label pattern hid the id from the
+ * arg parser). The label form is now accepted alongside the bare id.
+ * The `<agent>` half of the label is verified against the resolved
+ * agent so a mistyped estate is a refusal, never a silent no-op on
+ * this estate's plists.
+ *
+ * @param {string} input
+ * @param {string} agent
+ * @returns {{ id: string, accepted: 'id'|'label' }}
+ * @throws {Error & { exitCode: 2 }} when the label carries a different agent.
+ */
+export function normaliseScheduleArg(input, agent) {
+  const match = /^com\.([a-z0-9][a-z0-9-]*)\.(.+)$/.exec(input);
+  if (!match) return { id: input, accepted: 'id' };
+  const [, labelAgent, id] = match;
+  if (labelAgent !== agent) {
+    const err = new Error(
+      `scheduler remove: label form "com.${labelAgent}.${id}" names a different `
+      + `agent (${labelAgent}) than the resolved agent (${agent}). Refusing to touch `
+      + 'another estate\'s schedules. Pass `--agent <name>` to target a specific '
+      + 'estate on this laptop, or use the bare id form.',
+    );
+    err.exitCode = 2;
+    throw err;
+  }
+  return { id, accepted: 'label' };
+}
+
+/**
+ * Resolve the schedules directory for the invoking instance. Local
+ * resolution first (options.repoRoot, else the resolver's walk), then
+ * PA_ROOT as an explicit override, then DAVE_ROOT accepted as a
+ * deprecated alias with a one-line stderr notice. 0.1.53 item E.
+ *
+ * @param {object} options
+ * @returns {string}
+ */
+function schedulesRoot(options) {
+  if (options.repoRoot) return join(options.repoRoot, 'schedules');
+  const local = findRepoRootSync();
+  if (process.env.PA_ROOT) return join(process.env.PA_ROOT, 'schedules');
+  if (process.env.DAVE_ROOT) {
+    process.stderr.write(
+      'Notice: DAVE_ROOT is a deprecated alias for PA_ROOT. Set PA_ROOT '
+      + 'instead; DAVE_ROOT support will be removed in a future release.\n',
+    );
+    return join(process.env.DAVE_ROOT, 'schedules');
+  }
+  return join(local, 'schedules');
+}
+
+/**
+ * Read the `backend` field from a schedule file when the operator did
+ * not pass `--backend` (0.1.53 item D). Falls back to the host's
+ * OS-native default via `detect()` when the file exists but its
+ * `backend` field is null or missing. Refuses (exit 2) when neither
+ * source produces a supported backend, with a message naming the
+ * available options.
+ *
+ * @param {string} schedId
+ * @param {object} options
+ * @returns {string}
+ * @throws {Error & { exitCode: 2 }}
+ */
+function resolveBackendFromDisk(schedId, options) {
+  const file = join(schedulesRoot(options), `${schedId}.json`);
+  let sched = null;
+  if (existsSync(file)) {
+    try {
+      sched = JSON.parse(readFileSync(file, 'utf8'));
+    } catch { /* keep sched null */ }
+  }
+  if (sched && typeof sched.backend === 'string' && sched.backend.length > 0) {
+    return sched.backend;
+  }
+  // Fall back to the host's OS-native default. install() has always
+  // used the schedule file's `backend` field or the CLI-supplied value;
+  // for remove(), when nothing is on disk we still have to pick one, so
+  // we lean on the host detector rather than refuse.
+  const info = detect();
+  const pick = (info.available || []).find((b) => b.recommended)
+    || (info.available || [])[0];
+  if (pick && pick.backend) return pick.backend;
+  const err = new Error(
+    `scheduler remove: cannot resolve backend for "${schedId}" — no schedule file at ${file} `
+    + 'and no OS-native backend detected on this host. Pass --backend cron|launchd|systemd|schtasks explicitly.',
+  );
+  err.exitCode = 2;
+  throw err;
+}
+
 // ── Main ─────────────────────────────────────────────────────────────
 
 /**
  * Remove a schedule from the specified backend for the invoking
  * instance (or an explicit `--agent` override).
  *
+ * 0.1.53 item D usability fixes:
+ *   - `backend` is optional; when omitted, the schedule id's on-disk
+ *     `backend` field is honoured (fallback: OS-native detect).
+ *   - `schedId` accepts the label form (`com.<agent>.<id>`) as well as
+ *     the bare id, so operators pasting the label from `scheduler list`
+ *     no longer hit `Unknown backend: undefined`.
+ *
  * Same BUG-2-class fix as install(): this used to have no return
  * statement, so the CLI wrapper's `result.ok` check was reading
  * `undefined.ok`. Every path now returns a result object.
  *
- * @param {string} schedId - Schedule identifier
- * @param {string} backend - Backend name (cron, launchd, systemd, schtasks)
+ * @param {string} schedId - Schedule identifier or `com.<agent>.<id>` label
+ * @param {string} [backend] - Backend name (cron, launchd, systemd, schtasks).
+ *   Omit to resolve from the schedule file (with OS-native detect as fallback).
  * @param {object} [options]
  * @param {boolean} [options.deleteFile=false] - Also delete the schedule JSON file
  * @param {string} [options.agent] - Explicit agent override. Falls
  *   back to the invoking instance's `paName` from preferences.json.
  * @param {string} [options.repoRoot] - Optional instance root override
  *   (tests inject; production callers omit this).
- * @returns {{ ok: boolean, id: string, backend: string, agent: string }}
+ * @returns {{ ok: boolean, id: string, backend: string, agent: string, accepted: 'id'|'label' }}
  */
 export function remove(schedId, backend, options = {}) {
-  // See list.mjs for the same ordering rationale: backend validation
-  // must run BEFORE agent resolution so an unknown backend is a
-  // usage-shaped error, not a scheduler-config-shaped one.
-  if (backend !== 'cron' && backend !== 'launchd' && backend !== 'systemd' && backend !== 'schtasks') {
-    throw new Error(`Unknown backend: ${backend}. Supported: cron, launchd, systemd, schtasks`);
-  }
   const { agent } = resolveAgent({ agent: options.agent, repoRoot: options.repoRoot });
+  const { id, accepted } = normaliseScheduleArg(schedId, agent);
+  const resolvedBackend = backend || resolveBackendFromDisk(id, options);
+  if (resolvedBackend !== 'cron' && resolvedBackend !== 'launchd' && resolvedBackend !== 'systemd' && resolvedBackend !== 'schtasks') {
+    throw new Error(`Unknown backend: ${resolvedBackend}. Supported: cron, launchd, systemd, schtasks`);
+  }
 
-  switch (backend) {
-    case 'cron':     removeCron(schedId, agent); break;
-    case 'launchd':  removeLaunchd(schedId, agent); break;
-    case 'systemd':  removeSystemd(schedId, agent); break;
-    case 'schtasks': removeSchtasks(schedId, agent); break;
+  switch (resolvedBackend) {
+    case 'cron':     removeCron(id, agent); break;
+    case 'launchd':  removeLaunchd(id, agent); break;
+    case 'systemd':  removeSystemd(id, agent); break;
+    case 'schtasks': removeSchtasks(id, agent); break;
   }
 
   if (options.deleteFile) {
-    const daveRoot = process.env.DAVE_ROOT || process.env.PA_ROOT || options.repoRoot || findRepoRootSync();
-    const schedFile = join(daveRoot, 'schedules', `${schedId}.json`);
+    const schedFile = join(schedulesRoot(options), `${id}.json`);
     if (existsSync(schedFile)) {
       unlinkSync(schedFile);
       console.log(`Deleted schedule file: ${schedFile}`);
     }
   }
 
-  return { ok: true, id: schedId, backend, agent };
+  return { ok: true, id, backend: resolvedBackend, agent, accepted };
 }
 
 // ── CLI entry point ──────────────────────────────────────────────────

package/dist/engineering-pa-core/src/scheduler/verify.mjs

@@ -37,6 +37,7 @@ import {
   withLaunchdDefaults,
   buildCronCommand,
   detectNvm,
+  schedAgent,
 } from './install.mjs';
 import { detect } from './detect.mjs';
 
@@ -289,7 +290,7 @@ export async function verify(scheduleFile, opts = {}) {
   if (backend === 'cron') {
     const explicit = resolveEnvironment(sched);
     const hasNvm = opts.hasNvm ?? detectNvm();
-    const logPath = opts.cronLogPath ?? `/tmp/${sched.agent || 'dave'}-${sched.id}-verify.log`;
+    const logPath = opts.cronLogPath ?? `/tmp/${schedAgent(sched)}-${sched.id}-verify.log`;
     const { inner } = buildCronCommand(sched, workDir, explicit, { hasNvm, logPath });
     run = await runVerifyArgv('bash', ['-c', inner], workDir, env, timeoutMs);
   } else {