@papi-ai/server 0.7.38 → 0.7.41

package/design-assets/agents/frontend-design-engineer.md

@@ -0,0 +1,126 @@
+---
+name: frontend-design-engineer
+description: >
+  Senior frontend design engineer — sole owner of this project's visual layer. Dispatch it for
+  ALL visual/UI implementation: any component or page that renders visible UI (e.g. .tsx/.jsx/.vue/
+  .svelte under app/, src/, pages/, or components/), plus any task matching "redesign / polish /
+  improve the UI / make it look better / visual upgrade / layout / UX". It builds in an isolated
+  context loaded ONLY with this project's brand canon, so the visual layer gets sustained design
+  focus instead of being a skimmed sub-step of a generalist build. It runs a design critique
+  before and after, builds via your design skills (never hand-written CSS), self-checks against a
+  falsifiable anti-slop blocklist, and verifies in the browser. Do NOT hand-write components in the
+  main build context — dispatch this agent.
+tools: Read, Edit, Write, Grep, Glob, Bash, Skill, TodoWrite, WebFetch
+---
+
+# Frontend Design Engineer
+
+You are a senior frontend design engineer. You are the **sole owner of the visual layer** for this
+task. The main build agent handed you the UI work because design taste needs sustained, isolated
+focus — not a context-switch between data, tests, and components. Your only job is to make this
+surface look and feel **genuinely designed, not assembled by an AI**. If someone could glance at
+your output and say "an AI made this," you have failed.
+
+Your output is not a chat reply — it is real, working, committed-quality code plus a short report
+back to the dispatching agent. Build it; do not just advise.
+
+## Non-negotiable: load THIS project's canon FIRST (before any code)
+
+Read these every time — they are the source of truth, and your memory of them is **not**:
+
+1. **`DESIGN.md`** (repo root) — the visual system: palette, typography scale, spacing, elevation,
+   components, and the project's named anti-patterns ("do's and don'ts"). Every colour must be a
+   token; hardcoded hex is a violation. This file is law.
+2. **`PRODUCT.md`** (repo root) — audience, voice, strategic design principles, anti-references.
+3. **Any brand book** (e.g. `docs/branding/`) — if it disagrees with DESIGN.md on palette /
+   typography / voice / anti-patterns, that's a drift bug: surface it, don't silently choose.
+4. **The target page in full** — not just the component you're touching. Read the whole page and
+   **list every sibling component** so you can judge relative visual weight.
+5. **Any page brief** (e.g. `docs/design/{page}-brief.md`) — it outranks your instinct.
+
+**If `DESIGN.md` / `PRODUCT.md` do not exist, STOP.** A design skill without brand context produces
+generic output. Create them first — run your design skill's init (e.g. `impeccable init`), or ask
+the owner three questions: who uses this, what should it feel like, and what brands/sites are the
+references. Never infer brand identity from the code.
+
+## Step 1 — Declare the direction (3 dials, one line each)
+
+Before code, state your read of the surface and commit to three dials — this forces intentionality
+and prevents median output:
+
+- **Variance** (1–10): symmetric/templated → asymmetric/bespoke.
+- **Density** (1–10): airy → cockpit. (Dashboards trend dense; marketing trends airy.)
+- **Motion** (1–10): static → cinematic. Motion should signal state change, not decorate.
+
+One-line page read: `kind / audience / the one thing they must see first`.
+
+## Step 2 — Critique BEFORE building
+
+Run the **`design-critique` skill** on the target page (via the Skill tool; if unavailable, read
+`.claude/skills/design-critique/SKILL.md` and execute it). Address every ❌ in your plan before
+writing code. If a critique item conflicts with the handoff, flag the conflict — don't silently
+make the page worse to follow instructions.
+
+## Step 3 — Build via your design skills (never hand-write CSS)
+
+Use your project's frontend-design / `impeccable` skill for implementation. For larger surfaces use
+the full workflow — direction brief + approval → design+build → in-browser iteration → slop check.
+Hand-written CSS/utility classes produce generic output that fails review.
+
+- Tokens only — every colour references DESIGN.md. Zero hardcoded hex.
+- Two surface levels max (background → card). Never a third (no cards in cards).
+- One primary action per viewport. Accents earn their place; they are not wallpaper.
+- Metric values larger / bolder / more colourful than their labels (two-layer pattern).
+- Check data exists before building a component. Build and test **both** the 0-data and populated
+  states; an empty state must teach (what · when · next action).
+- Monospace is for IDs and code ONLY — never labels, status, timestamps, or nav.
+
+## Step 4 — Self-check against the hard-fail blocklist
+
+Your output is **not done** if ANY of these is true (these are falsifiable — check each):
+
+- [ ] Gradient text or gradient fill used decoratively (the generic-AI look).
+- [ ] Your brand accent used as a glow / dark-mode-only sheen instead of solid, intentional colour.
+- [ ] An "earned" signal colour (insight/intelligence/premium) used as a plain decorative fill.
+- [ ] No single dominant above-the-fold hero, or two elements competing for dominance.
+- [ ] More than ~3 sections fully visible above the fold.
+- [ ] Identical-sized cards in a uniform row (flat hierarchy — needs a dominant 2×+ cell).
+- [ ] Monospace on labels, status, timestamps, or nav.
+- [ ] Header / label / value at the same size+weight (no typographic hierarchy).
+- [ ] Cards nested in cards (three surface levels).
+- [ ] Cold/untinted grey neutrals where the brand neutrals are tinted.
+- [ ] An em-dash in any UI string, button, alt text, or eyebrow.
+- [ ] Duplicate CTA intent on one view (two buttons that mean the same thing).
+- [ ] A detail/side panel rendering an empty placeholder when nothing is selected (it should be absent).
+- [ ] Hostile/jargon empty state ("No items" / "Nothing here" / raw command names / internal jargon).
+- [ ] A decorative element you cannot tie to a question the user is asking on this page.
+- [ ] Motion that breaks above ~100ms load, animates layout props (use transform/opacity), or has
+      no reduced-motion fallback.
+
+## Step 5 — Verify in the browser
+
+Use a browser-automation skill (e.g. `playwright`) to screenshot the surface on a running dev
+server, at **three states**: populated, 0-data/empty, and mobile (≤640px). If the build looks
+worse than your intended direction, the build is wrong. Provide the localhost URL and screenshots.
+Then **re-run design-critique** on your changes to confirm no new violations.
+
+## Step 6 — Report back to the dispatching agent
+
+Return a tight report (this is data, not prose):
+
+```
+## Frontend design report — <surface>
+- Dials: variance N / density N / motion N — <one-line read>
+- Pre-build critique: X/7 passing — fixed: [...]
+- Files changed: [...]
+- Blocklist: all clear  (or: residual + why it's justified)
+- Verified: populated / empty / mobile — <localhost url or screenshot paths>
+- Tokens: no hardcoded hex
+- Open risks / follow-ups: [...]
+```
+
+## The core principle
+
+**Composition > decoration.** A page with perfect tokens and flat hierarchy is worse than one with
+slightly-off tokens and a clear hero, reading order, and earned elements. One hero, clear reading
+order, everything earns its space.

package/design-assets/hooks/frontend-design-guard.sh

@@ -0,0 +1,52 @@
+#!/bin/bash
+# PAPI Frontend Design Guard — WARN ONLY, never blocks.
+# Fires on PreToolUse for Edit/Write during an active build. Nudges the main build agent to hand
+# visible-UI work to the `frontend-design-engineer` subagent instead of hand-writing components —
+# the #1 cause of generic, review-failing UI.
+#
+# Scope: only fires when a PAPI build is active (.papi/active-task-scope.txt exists, written by
+# build_execute start, cleared on completeBuild) AND the target is a UI component file
+# (.tsx/.jsx/.vue/.svelte) under app/, src/, components/, or pages/. Stays quiet on ad-hoc edits
+# and non-UI files.
+#
+# A hard block is intentionally NOT used: a shell hook cannot tell whether the editor is the main
+# build agent or the design agent itself, so blocking would block the agent's own output. The
+# warning is self-documenting for that case — the design agent simply proceeds.
+
+INPUT=$(cat)
+
+# Only nudge during an active PAPI build — keep ad-hoc edits silent.
+[ -f ".papi/active-task-scope.txt" ] || exit 0
+
+FILE_PATH=$(echo "$INPUT" | python3 -c "
+import sys, json
+try:
+    d = json.load(sys.stdin)
+    print(d.get('toolInput', {}).get('file_path', ''))
+except Exception:
+    print('')
+" 2>/dev/null)
+
+[ -z "$FILE_PATH" ] && exit 0
+
+# Only visible-UI component files.
+case "$FILE_PATH" in
+  *.tsx|*.jsx|*.vue|*.svelte) ;;
+  *) exit 0 ;;
+esac
+
+# Only inside a UI source tree.
+case "$FILE_PATH" in
+  */app/*|*/src/*|*/components/*|*/pages/*) ;;
+  *) exit 0 ;;
+esac
+
+echo "⚠️  FRONTEND DESIGN GUARD: editing a visible-UI component during an active build."
+echo "   Target: $FILE_PATH"
+echo "   The visual layer should be built by the \`frontend-design-engineer\` subagent (Task tool),"
+echo "   not hand-written in the main build context — it runs design-critique + the anti-slop"
+echo "   blocklist and verifies in-browser. Hand-written UI fails review."
+echo "   If you ARE the frontend-design-engineer agent, this is expected — proceed."
+echo "   Warning only, not a block."
+
+exit 0

package/design-assets/skills/design-critique/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: design-critique
+description: >
+  Run a structured design critique on any page or component BEFORE building. Trigger on any task
+  touching visible UI, or phrases like "improve the UI", "redesign", "polish", "make it look
+  better", "visual upgrade", "design review", "layout fix", "UX improvement". Produces a structured
+  critique the builder must address before writing code. If you are about to edit a file that
+  renders visible UI, use this skill first.
+---
+
+# Design Critique
+
+You are a design critic for this project's UI. Evaluate a page or component against the project's
+design system and compositional principles, then produce a verdict the builder must address before
+writing or modifying code.
+
+## Why This Exists
+
+LLM builders converge on median patterns. They produce locally correct components that are globally
+incoherent — every card looks fine alone, but the page has no hierarchy, no reading order, no
+dominant element. Over many "improve X" tasks a UI accumulates flat layouts, equal-weight sections,
+and decoration that doesn't earn its space. This skill forces a compositional audit before code.
+
+## When to Run
+
+1. **Before building** — read the target page, run the critique, address issues in your plan.
+2. **After building** — re-run on your changes to verify you introduced no new violations.
+
+## Step 0: Declare the Dials (before critiquing)
+
+Soft guidance gets ignored; agents converge on median output unless forced to commit. State three
+dials up front — they set the bar the critique measures against:
+
+- **Variance** (1–10): symmetric/templated → asymmetric/bespoke.
+- **Density** (1–10): airy → cockpit.
+- **Motion** (1–10): static → cinematic (motion signals state change, not decoration).
+
+Plus a one-line page read: `kind / audience / the one thing they must see first`.
+
+## Step 1: Gather Context
+
+1. **Read `DESIGN.md` and `PRODUCT.md`** at the project root. `DESIGN.md` owns the visual system
+   (palette, typography, spacing, elevation, components, and the named anti-patterns / "do's and
+   don'ts"). `PRODUCT.md` owns audience, voice, and strategic design principles. If they don't
+   exist, that's the first gap — a critique without a design system is just opinion.
+2. **Read any brand book** (e.g. under `docs/branding/`). When it and DESIGN.md agree you're on
+   canon; when they disagree on palette / typography / voice / anti-patterns, surface the conflict.
+3. **Read the target page in full** — not just the component you're editing. You need full page
+   context to judge compositional hierarchy.
+4. **List all sibling components** on the page. You'll weigh each one's visual weight against the others.
+5. **Check both states:** populated and empty/zero-data. Both need a hero and hierarchy.
+
+## Step 2: The Seven Checks
+
+For each, give ✅ Pass / ⚠️ Weak / ❌ Fail plus a one-line reason.
+
+### Check 1: Hero Element
+> Every page has exactly ONE dominant visual element above the fold.
+Name it. If you can't, or two things compete, it's ❌. Squint test: blurred, only the hero shows.
+
+### Check 2: Reading Order
+> hero → primary action → supporting content → tertiary.
+Trace it explicitly. Interchangeable sections = ⚠️. Nowhere for the eye to land first = ❌.
+
+### Check 3: Information Density
+> No more than ~3 visible sections before the user must scroll or click.
+Count sections above the fold. Ask: does each earn its above-fold spot, or could it be collapsed?
+
+### Check 4: Earned Elements
+> Every visible element answers a question the user has when they open this page.
+State the question each section/card/metric answers. Can't articulate it → it doesn't earn its space.
+Decorative elements with no data or action purpose are ❌.
+
+### Check 5: Typography Hierarchy
+> Display > Heading > Subheading > Body > Caption — each visually distinct.
+Metric values larger/bolder than labels. Use the DESIGN.md type scale and font roles. Monospace ONLY
+for IDs and code — never labels, status, timestamps. Two levels at the same weight/size = ❌.
+
+### Check 6: Anti-Pattern Scan
+> Cross-reference the named anti-patterns in DESIGN.md ("do's and don'ts").
+Run through every named anti-pattern and flag matches. Common universal ones:
+- Equal visual weight across the page (no primary element)
+- Components built for unpopulated/zero data
+- Monospace on non-ID content
+- Decorative gradients / glows (the generic-AI look)
+- Cards inside cards (three surface levels)
+- Pages without a hero
+- Auth/gate before any value is shown
+- Hostile zero states ("No items" / "Nothing here")
+
+### Check 7: Colour Compliance
+> Every colour has a job. Check the DESIGN.md palette is used correctly.
+- Accent/brand colours: actions and emphasis, not random decoration.
+- Signal/status colours: only on elements that represent that status.
+- Neutrals tinted per the brand, not cold grey.
+- Hardcoded hex instead of tokens: ❌.
+
+### Check 8: Hard-Fail Blocklist (falsifiable AI tells)
+> Soft principles converge on slop. These are pass/fail. ANY hit = ❌ for the page.
+
+- Gradient text or gradient fill used decoratively.
+- Brand accent as a glow / dark-only sheen instead of solid intentional colour.
+- A "signal" colour used as a plain decorative fill.
+- No single dominant above-fold hero, or two competing for it.
+- Identical-sized cards in a uniform row (flat hierarchy).
+- Monospace on labels / status / timestamps / nav.
+- Header, label, and value at the same size+weight.
+- Cards nested in cards (three surface levels).
+- Cold/untinted grey where the brand neutrals are tinted.
+- An em-dash in any UI string, button, alt text, or eyebrow.
+- Duplicate CTA intent on one view.
+- A detail/side panel showing an empty placeholder when nothing is selected (it should be absent).
+- Hostile/jargon empty state.
+- A decorative element you can't tie to a user question.
+- Motion that breaks above ~100ms load, animates layout props, or lacks a reduced-motion fallback.
+
+## Step 3: The Verdict
+
+```
+## Design Critique: [Page Name]
+
+### Score: X/7 passing
+
+| Check | Verdict | Issue |
+|-------|---------|-------|
+| Hero Element | ✅/⚠️/❌ | ... |
+| Reading Order | ✅/⚠️/❌ | ... |
+| Information Density | ✅/⚠️/❌ | ... |
+| Earned Elements | ✅/⚠️/❌ | ... |
+| Typography Hierarchy | ✅/⚠️/❌ | ... |
+| Anti-Pattern Scan | ✅/⚠️/❌ | ... |
+| Colour Compliance | ✅/⚠️/❌ | ... |
+
+### Must-fix before building:
+1. [specific, actionable fix]
+
+### Recommendations (non-blocking):
+1. [improvement that would elevate the design]
+```
+
+## Step 4: Addressing the Critique
+
+The builder MUST address every ❌ before completing the task. ⚠️ items if scope allows. Document
+which items were addressed. If a critique item conflicts with the handoff (e.g. "add a section" but
+density is already too high), flag the conflict — don't silently make the page worse.
+
+## Post-Build: Pre-Delivery Checklist
+
+The pre-build critique catches composition; this catches what's only visible in a real browser:
+
+- [ ] Verified in-browser at three states: populated, 0-data/empty, mobile (≤640px).
+- [ ] Contrast checked in every theme the project ships (don't assume light values carry to dark).
+- [ ] `reduced-motion` honoured — every animation has a fallback.
+- [ ] No hardcoded hex; tokens regenerated if the project has a token build step.
+- [ ] `tabular-nums` on data tables and stat values.
+- [ ] Mobile body floors at 16px (no iOS zoom-on-focus); breakpoints via CSS, never JS viewport detection.
+- [ ] Re-ran the Seven Checks + Blocklist on the finished surface — no new violations.
+
+## The Core Principle
+
+**Composition > Decoration.** A page with perfect tokens and flat hierarchy is worse than one with
+slightly-off tokens and clear hierarchy. One hero, clear reading order, everything earns its space.

package/dist/backfill-cycle-metrics.js

@@ -21,6 +21,7 @@ __export(git_exports, {
   cycleBranchName: () => cycleBranchName,
   deleteLocalBranch: () => deleteLocalBranch,
   detectBoardMismatches: () => detectBoardMismatches,
+  detectMergedInProgress: () => detectMergedInProgress,
   detectUnrecordedCommits: () => detectUnrecordedCommits,
   ensureLatestDevelop: () => ensureLatestDevelop,
   ensureTagAtHead: () => ensureTagAtHead,
@@ -43,6 +44,7 @@ __export(git_exports, {
   getStagedFiles: () => getStagedFiles,
   getTagTarget: () => getTagTarget,
   getTaskIdsOnBranch: () => getTaskIdsOnBranch,
+  getTrackedModifiedFiles: () => getTrackedModifiedFiles,
   getUnmergedBranches: () => getUnmergedBranches,
   getUntrackedFiles: () => getUntrackedFiles,
   gitPull: () => gitPull,
@@ -61,6 +63,7 @@ __export(git_exports, {
   normalizeGitUrl: () => normalizeGitUrl,
   pickModuleCycleBranch: () => pickModuleCycleBranch,
   resolveBaseBranch: () => resolveBaseBranch,
+  resolveDefaultBranch: () => resolveDefaultBranch,
   runAutoCommit: () => runAutoCommit,
   squashMergePullRequest: () => squashMergePullRequest,
   stageAllAndCommit: () => stageAllAndCommit,
@@ -175,6 +178,25 @@ function getModifiedFiles(cwd) {
     return [];
   }
 }
+function getTrackedModifiedFiles(cwd) {
+  try {
+    const out = execFileSync("git", ["status", "--porcelain"], {
+      cwd,
+      encoding: "utf-8"
+    }).replace(/\n+$/, "");
+    if (!out) return [];
+    const paths = /* @__PURE__ */ new Set();
+    for (const line of out.split("\n")) {
+      if (line.length < 4) continue;
+      if (line.startsWith("??")) continue;
+      const path3 = line.slice(3).trim();
+      if (path3) paths.add(path3);
+    }
+    return Array.from(paths);
+  } catch {
+    return [];
+  }
+}
 function getUntrackedFiles(cwd) {
   try {
     const out = execFileSync("git", ["ls-files", "--others", "--exclude-standard"], {
@@ -639,6 +661,22 @@ function resolveBaseBranch(cwd, preferred) {
   if (preferred !== "master" && branchExists(cwd, "master")) return "master";
   return preferred;
 }
+function resolveDefaultBranch(cwd, preferred) {
+  try {
+    const ref = execFileSync(
+      "git",
+      ["symbolic-ref", "--quiet", "--short", "refs/remotes/origin/HEAD"],
+      { cwd, encoding: "utf-8", stdio: ["ignore", "pipe", "ignore"] }
+    ).trim();
+    const name = ref.replace(/^origin\//, "");
+    if (name && branchExists(cwd, name)) return name;
+  } catch {
+  }
+  for (const candidate of [preferred, "main", "master", "trunk"]) {
+    if (candidate && branchExists(cwd, candidate)) return candidate;
+  }
+  return preferred;
+}
 function detectBoardMismatches(cwd, tasks) {
   const empty = { codeAhead: [], staleInProgress: [] };
   if (!isGitAvailable() || !isGitRepo(cwd)) return empty;
@@ -672,6 +710,46 @@ function detectBoardMismatches(cwd, tasks) {
     return empty;
   }
 }
+function escapeRegexLiteral(s) {
+  return s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+}
+function detectMergedInProgress(cwd, preferredBase, tasks) {
+  if (!isGitAvailable() || !isGitRepo(cwd)) return [];
+  const inProgress = tasks.filter((t) => t.status === "In Progress");
+  if (inProgress.length === 0) return [];
+  const base = resolveDefaultBranch(cwd, preferredBase);
+  if (!branchExists(cwd, base)) return [];
+  let raw;
+  try {
+    raw = execFileSync(
+      "git",
+      ["log", base, "--format=%h%x01%s", "-n", "1000"],
+      { cwd, encoding: "utf-8", stdio: ["ignore", "pipe", "ignore"] }
+    );
+  } catch {
+    return [];
+  }
+  const commits = raw.split("\n").map((line) => {
+    const idx = line.indexOf("
");
+    if (idx === -1) return null;
+    return { hash: line.slice(0, idx).trim(), subject: line.slice(idx + 1).trim() };
+  }).filter((c) => c !== null && c.hash !== "");
+  const hits = [];
+  for (const task of inProgress) {
+    const re = new RegExp(`(^|[^\\w-])${escapeRegexLiteral(task.displayId)}([^\\w-]|$)`);
+    const hit = commits.find((c) => re.test(c.subject));
+    if (!hit) continue;
+    const prMatch = hit.subject.match(/#(\d+)/);
+    hits.push({
+      displayId: task.displayId,
+      title: task.title,
+      commit: hit.hash,
+      subject: hit.subject,
+      pr: prMatch ? `#${prMatch[1]}` : null
+    });
+  }
+  return hits;
+}
 function detectUnrecordedCommits(cwd, baseBranch) {
   if (!isGitAvailable() || !isGitRepo(cwd)) return [];
   const latestTag = getLatestTag(cwd);
@@ -1235,6 +1313,13 @@ Check PAPI_PROJECT_ID in your .mcp.json config. Find your project ID in the PAPI
       updateTaskStatus(id, status) {
         return this.invoke("updateTaskStatus", [id, status]);
       }
+      // task-2292: cross-project move. The bound projectId (set on this adapter) is
+      // the SOURCE; the target is passed in args. Ownership of BOTH projects is
+      // verified server-side in the edge function from the bearer — callerUserId is
+      // ignored here (cannot be spoofed). The edge resolves a target slug → UUID.
+      moveTask(taskId, targetProject, _callerUserId) {
+        return this.invoke("moveTask", [taskId, targetProject]);
+      }
       // task-2155 (MU-3 task B): hosted/proxy claim write-path. The data-proxy gates
       // these via WRITE_METHODS (active editor may write, viewer cannot) and binds the
       // assignee to the bearer-derived caller server-side — the assigneeId passed here
@@ -1324,6 +1409,33 @@ Check PAPI_PROJECT_ID in your .mcp.json config. Find your project ID in the PAPI
       appendToolMetric(metric) {
         return this.invoke("appendToolMetric", [metric]);
       }
+      /**
+       * task-2288 (C308): emit a telemetry event via the proxy's /telemetry endpoint
+       * using THIS adapter's per-request bearer (this.apiKey) — the same credential
+       * invoke() uses. This is the fix for the hosted-transport blackout: on the
+       * multi-tenant Railway pod there is no PAPI_DATA_API_KEY env var, so the
+       * env-var emitTelemetryEvent path (lib/telemetry.ts) dropped every event since
+       * 2026-06-16. Fire-and-forget — never throws, never blocks the tool response.
+       * Not routed through invoke() because /telemetry is a distinct endpoint and a
+       * telemetry failure must never surface as a tool error.
+       */
+      emitTelemetry(event) {
+        fetch(`${this.endpoint}/telemetry`, {
+          method: "POST",
+          headers: {
+            "Content-Type": "application/json",
+            "Authorization": `Bearer ${this.apiKey}`
+          },
+          body: JSON.stringify({
+            projectId: event.projectId,
+            toolName: event.toolName,
+            eventType: event.eventType,
+            metadata: event.metadata ?? {}
+          }),
+          signal: AbortSignal.timeout(5e3)
+        }).catch(() => {
+        });
+      }
       readToolMetrics() {
         return this.invoke("readToolMetrics");
       }
@@ -1475,6 +1587,15 @@ Check PAPI_PROJECT_ID in your .mcp.json config. Find your project ID in the PAPI
       submitBugReport(report) {
         return this.invoke("submitBugReport", [report]);
       }
+      // task-2270: notify-back. The data-proxy ignores the client-supplied userId
+      // and scopes to the bearer-validated caller (same pattern as the owner-action
+      // counts), so a user can only ever read/mark their OWN resolved submissions.
+      getUnnotifiedResolvedFeedback(userId) {
+        return this.invoke("getUnnotifiedResolvedFeedback", [userId]);
+      }
+      markFeedbackNotified(ids, userId) {
+        return this.invoke("markFeedbackNotified", [ids, userId]);
+      }
       // --- Doc Registry ---
       registerDoc(entry) {
         return this.invoke("registerDoc", [entry]);