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

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

@@ -36,6 +36,11 @@ Usage:
 
 Notes:
   - status=done stamps \`completedAt\` to today (only if not already set).
+  - \`list\` defaults to the active-only scope (excludes done + archived).
+    An explicit \`--status <s>\` REPLACES that default and returns only
+    items with that status (so \`--status done\` prints done items).
+    \`--all\` means no status filter; \`--mine\`/\`--theirs\` compose with
+    either. \`--status\` wins over \`--all\` when both are given.
   - --mine resolves the PA name from operator/config/preferences.json
     (paName / agentName). Default: "pa".
   - --author sets the writer-scoped id's author token. Precedence:

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

@@ -228,6 +228,15 @@ export async function setWorkStatus(id, status) {
  * mine, theirs, all, paName (used for --mine resolution).
  * By default excludes done + archived (mirrors desk-list semantics).
  *
+ * An explicit `status` filter REPLACES the active-only default rather
+ * than being AND-ed with it: `--status done` returns only done items,
+ * `--status archived` returns only archived items, `--status in-progress`
+ * is unchanged (the AND was harmless for non-terminal statuses). The
+ * pre-0.1.52 AND made any terminal-status request unconditionally
+ * empty ("no work items match" for `--status done`), a confident false
+ * negative. `--all` still means "no status filter at all"; if both
+ * `--all` and `--status` are given, `--status` wins.
+ *
  * Reads any well-formed work item (both id forms). Skips files whose
  * filename does not parse as a work-item id at all — the same
  * skip-unparseable posture the original had, restated against the
@@ -248,10 +257,11 @@ export async function listWork(filters = {}) {
     }
   }
   let filtered = items;
-  if (!filters.all) {
+  if (filters.status) {
+    filtered = filtered.filter((w) => w.status === filters.status);
+  } else if (!filters.all) {
     filtered = filtered.filter((w) => !['done', 'archived'].includes(w.status));
   }
-  if (filters.status) filtered = filtered.filter((w) => w.status === filters.status);
   if (filters.category) filtered = filtered.filter((w) => w.category === filters.category);
   if (filters.project) filtered = filtered.filter((w) => w.projectId === filters.project);
   if (filters.owner) filtered = filtered.filter((w) => w.owner === filters.owner);

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

@@ -25,18 +25,27 @@ 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
 
 Schedule files live at <repoRoot>/schedules/<id>.json. The canonical
 schema is bundled at @stravica-ai/engineering-pa-core/schema/schedule.json.
 
---agent (launchd only) targets a specific agent's label prefix
-(com.<agent>.<id>). A schedule file's own top-level "agent" field drives
-install; list/remove take it explicitly since they don't read a schedule
-file. Defaults to "dave" everywhere — omitting it is unchanged behaviour.
+--agent targets a specific agent's label / tag prefix. Install reads
+the agent from the schedule file's own top-level "agent" field. Since
+0.1.52 (w-2026-09-19-dave-001), list/remove resolve the agent from the
+invoking instance's "paName" in operator/config/preferences.json when
+--agent is omitted, and REFUSE (exit 2) when neither source produces a
+value — there is no hard-coded "dave" fallback. This is the fix for the
+colleague-laptop bug where the tools would list and touch another
+estate's schedules under a silent default.
 
 Host enforcement (install): a schedule's "host" field is matched against
 this machine's hostname (exact, then short-name-before-first-dot). A

package/dist/engineering-pa-cli/src/secrets/commands/init.mjs

@@ -85,7 +85,41 @@ function parseStdinJson(raw) {
 }
 
 export async function runInit(overrides = {}) {
-  const paths = overrides.paths || defaultPaths({ ...overrides, allowGitRootWithoutVault: true });
+  // 0.1.52 fix (w-2026-09-19-dave-001): `secrets init` CREATES an age
+  // key. The shared resolver in core/vault/require.mjs honours
+  // SOPS_AGE_KEY_FILE first, so with the variable exported the previous
+  // init generated the new key AT the env path — a stray key landed
+  // outside the instance, and on a colleague laptop that carried
+  // another estate's SOPS_AGE_KEY_FILE it would have written the new
+  // key into that estate's key file. The env override is a READ-path
+  // escape hatch; init must generate at the instance path (solo mode)
+  // or the per-user path (HQ mode) regardless of the variable.
+  //
+  // Strip SOPS_AGE_KEY_FILE from the env passed to `defaultPaths` only
+  // — every OTHER env-derived resolution (DAVE_ROOT / PA_ROOT walk,
+  // etc.) still uses the caller's real env. Print a one-line notice
+  // when the operator had the override set and the resolved
+  // key path does not match it, so subsequent reads that continue to
+  // consult the env override are not silently pointed at the old file.
+  const rawEnv = overrides.env;
+  const envOverride = rawEnv && typeof rawEnv.SOPS_AGE_KEY_FILE === 'string' && rawEnv.SOPS_AGE_KEY_FILE.length > 0
+    ? rawEnv.SOPS_AGE_KEY_FILE
+    : null;
+  let envForPaths = rawEnv;
+  if (envOverride !== null && !overrides.paths) {
+    envForPaths = { ...rawEnv };
+    delete envForPaths.SOPS_AGE_KEY_FILE;
+  }
+  const paths = overrides.paths || defaultPaths({
+    ...overrides,
+    env: envForPaths,
+    allowGitRootWithoutVault: true,
+  });
+  if (envOverride !== null && envOverride !== paths.keyFile) {
+    console.log(
+      `Note: SOPS_AGE_KEY_FILE is set to ${envOverride}; init writes the new key to ${paths.keyFile}. Reads will not see the new key until the variable is unset or repointed.`,
+    );
+  }
   const argv = overrides.argv || [];
   const flags = extractInitFlags(argv);
 

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
@@ -207,10 +229,12 @@ Otherwise, tell the operator what is happening in one short paragraph:
 
 > Standing up your instance's own SOPS+age vault. This is what
 > credentialed tools read their keys from. The vault lives in
-> `.vault/`, the age private key lives in
-> `~/.config/stravica-pa/age-key.txt` (never committed), and the
-> encrypted store is safe to commit. Values you enter here never leave
-> your laptop.
+> `.vault/`, the age private key lives inside the instance at
+> `.vault/age-key.txt` (never committed), and the encrypted store is
+> safe to commit. Values you enter here never leave your laptop.
+> HQ-mode instances keep a per-user key at
+> `~/.config/stravica-pa/age-key.txt` instead (shared across the
+> estate's canonical clones).
 
 Ask, in one turn, for the values the enabled tools declare. For the
 default atlassian install:

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 ─────────────────────────────────────────────────
@@ -562,7 +610,7 @@ function validateLaunchdDaveRoot(value) {
       + '(DAVE_ROOT unset at install time, falling back to the installed '
       + 'package\'s own directory, which is version-pinned and silently breaks '
       + 'on the next upgrade or package rename). Set DAVE_ROOT explicitly in '
-      + 'the shell running `pa scheduler install`, or set the schedule\'s '
+      + 'the shell running `pnpm exec scheduler install`, or set the schedule\'s '
       + 'environment.DAVE_ROOT to the real operator repo root.',
     );
     e.exitCode = 2;
@@ -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');