PROPOSAL — Product Manager role for Mentor

Give a non-technical mentee real product control, on hard $50/mo guardrails

2026-08-23 · Claude Code (Mia) · status: proposal — nothing built until Byron's go

Live app: https://mentor.arnao.ai · Canonical state: [file:///Users/byronarnao/openclaw-gia/config/workspace/projects/mentor-app/CANONICAL-STATE.md](file:///Users/byronarnao/openclaw-gia/config/workspace/projects/mentor-app/CANONICAL-STATE.md)

---

1. The idea in one paragraph

A new server-verified role, pm (user-facing: Product Manager), lets a chosen mentee — no programming skill required — run the product: triage the incoming feedback/PR queue, email the user base, schedule Google Meet sessions, propose and prioritize features, watch an AI worker build them, test the preview, and drive the rollout (with Byron's 30-second tap gating each production promote in v1) — all inside guardrails that make it impossible for them to spend past a hard monthly cap, touch auth/roles/secrets, or steer the product off its mission. The expensive model (Opus 4.8) is their thinking partner; a cheap model (GLM via Z.ai's $10/mo coding plan) does the actual building. Total worst-case cost: ≤ $37/month, under the $50 ceiling with headroom.

Why this is cheap to build: Mentor already has ~70% of the chassis. Server-verified Google-email roles (meta/roles.json), an admin Controller with a Backlog & Releases queue (feedback auto-imports as MEN-NNN items; "Create PR" bundles a release brief), a working Gmail sender, per-user spend caps, and a global cost ledger are all live today. The PM role is mostly scoping existing power down, not building new power up.

---

2. What the PM can and cannot do

The "sell drugs" case: a Product Charter (§8) is the constitution. The copilot won't plan against it, the broadcast linter won't send against it, and any charter-flagged item lands in a needs-Byron queue instead of executing. The PM has autonomy inside the charter, a request path outside it — never silent power.

---

3. Role plumbing (the one genuinely fiddly part)

The codebase audit found a role string grants nothing unless wired in exactly four places — miss one and pm silently no-ops:

1. expandRoles() — _store.js:373 (pm expands to just pm)
2. roleFromReq() two-vocabulary collapse — _store.js:324 (pm maps to mentor-level for legacy checks, and never to admin)
3. viewerFromReq() — _store.js:461 (adds a viewer.pm boolean alongside admin/orchestrator)
4. ROLE_ACTIONS + per-action gates — user.js:308 (new second-stage pm_allowed check per §2's table)

Client side: the hardcoded 3-entry role modal (index.html:930) and loginGo() mapping gain a 4th entry → a PM console view: the existing Controller, minus the Cost-config/Users-admin controls, plus the new Comms / Copilot / Flags tabs. Granting the role = one line in meta/roles.json via the existing runtime roles action — no redeploy, revocable in seconds.

---

4. Comms: email the group, book the meetings

Broadcast — new admin-or-pm action broadcast {subject, body, audience}:

• Recipients from the existing ?list summary (email, name, test flag — test accounts excluded). User cap is 300 by design; that's the natural blast ceiling.
• Guardrails: 4 blasts/month (Blob counter, same pattern as the 5/hr notify limit) · mandatory send-to-self preview first · charter + quality lint (gemini-2.5-flash-lite: bans, tone, dead links, claims about features that don't exist) · unsubscribe/opt-out line mandatory (CAN-SPAM basics) · sends via the proven store.sendGmail path, throttled ~1/sec.
• First month: every blast is Byron-approved (Telegram tap) before send — an embarrassing-but-not-evil email is the PM's most likely failure, and lint can't catch tone. After a clean month, auto-send unlocks; flagged content always stays needs-byron.
• Sender identity moves off Byron's personal Gmail to a dedicated product address (e.g. a mentor@arnao.ai mailbox or Gmail alias with its own refresh token) — protects byron.arnao@gmail.com from spam-classification at 300 recipients and stops the PM's output reading as Byron personally. Byron stays BCC'd.
• Audience is re-validated server-side at send time against the actual user list — segments.json is names-of-registered-users only, so neither the PM nor a compromised PM account can blast arbitrary external addresses.

Meetings — new action meet {title, when, durationMin, audience}:

• Verified today: gog calendar create primary --with-meet --attendees=… works with Byron's already-authorized byron.arnao@gmail.com OAuth (calendar scope granted, gog v0.17.0 in the gia container). Zero new auth.
• Wiring: the Vercel endpoint writes a request blob meta/meet-queue.json; a Gia watcher cron (same pattern as the RAI refresh watcher) picks it up within 5 min, runs gog, writes the Meet link back; PM console shows it and can include it in a broadcast. Guardrails: 8 events/month; attendees re-validated against the user list; the watcher strict-schema-validates every field and invokes gog via an argv array, never a string-built shell command (no shell-injection path from attendee/title text).
• User group: skip Google Groups — a meta/segments.json (e.g. "beta-circle", "new-mentees") the PM edits in-console, used as the audience for both blasts and meetings. Simpler, no new Google surface.

---

5. The PM Copilot (planner = expensive, capped)

New AI mode pmplan in ai.js (mode #19, alongside the existing 18):

• Model: claude-opus-4-8 — already allowlisted at $5/$25 per Mtok. This is the "form their plans, interactive chat" partner. (Fable 5 was considered; it's the priciest tier and the delta doesn't matter for PM planning chat. Option: pin the monthly product review — one synthesis call/month — to Fable, ~$1/mo.)
• Context injected server-side: backlog snapshot, last-7-day activity rollup, feedback ledger themes, the Product Charter, and the app's feature map — so it coaches the PM on this product, not in the abstract. It knows how to turn a raw idea into a structured brief and files it as a MEN-NNN backlog item on request.
• Budget: hard $15/month via the existing per-user spend-cap machinery (rec.cap + settleSpend → 429 cap_reached) — the same code that protects the app today, no new enforcement to trust. At 80% burn the mode downgrades to gemini-2.5-flash ($0.30/$2.50) — visibly, with a console notice, never silently. Honest throughput math (Fable pass corrected the first estimate): with injected context at 15–30k input tokens/turn, $15 buys roughly 40–100 full Opus exchanges/month, not 200+. Mitigation: context is tiered — the full backlog/activity snapshot loads once per session, follow-up turns carry only the delta — targeting the high end of that range.
• This is also the PM's coach: same guidance-cue machinery mentees get (nudges, drift protection) pointed at PM goals — "3 feedback items have sat untriaged for 5 days," "you haven't talked to a user in 2 weeks."

---

6. The worker (builder = cheap) and deploy control

The PM's "Create PR" already produces a release brief and Telegram-pings ops. Today a human agent picks it up. The new piece is an executor daemon on Mia (launchd, like Security Sentinel):

1. Polls /api/backlog for queued releases (admin token, existing pickup contract).
2. Runs a headless Claude-Code-compatible coding harness pointed at Z.ai's GLM Coding Plan — Lite, $10/mo flat (plan docs, pricing). It exposes an Anthropic-compatible endpoint, so the harness needs only a base-URL + key swap; GLM-5.x benchmarks within ~4% of Opus on SWE-bench. Fallback tier for trivial tasks: z-ai/glm-5.2:free on OpenRouter — $0, ~200 req/day.
3. Builds on a branch, deploys a Vercel preview (never --prod), posts the preview URL + a server-computed deterministic diff (git diff --stat + changed-file list — never a model-written summary, since a compromised model would summarize its own backdoor honestly-sounding), marks picked_up.
4. PM tests the preview link (a non-coder can click a URL), then hits Promote → which in v1 always routes to Byron.

Executor security (the prompt-injection chain, taken seriously). Feedback items are attacker-authored text that flows into a coding model — so the pipeline assumes a hostile brief:

• Broker split: a dumb credential-holding poller (holds the backlog admin token) hands the GLM agent only the brief text, fenced as untrusted content. The agent's environment contains a preview-scoped Vercel token and the GLM key — never ADMIN_PW, FB_SECRET, Gmail creds, provider API keys, or the backlog admin token. Agent network egress is allowlisted (Z.ai, npm, Vercel).
• Preview isolation: preview deploys get a sandboxed env — a separate Blob store and test API keys, never the prod BLOB_READ_WRITE_TOKEN or prod provider keys. GLM-authored code never executes against production data pre-review. (Vercel scopes env per-environment; this is config, not new infra — but it's a P4 precondition, verified before the first real build.)
• Deploy hygiene from CANONICAL-STATE (sw-cache bump, node --check, never-break-Start-now smoke test) runs as hard scripted checks on the preview — the Promote button doesn't appear until they pass; the harness prompt is guidance, not the control.

Promote flow (v1, per the Fable adjudication): every promote requires Byron's tap — including "UI-only." Rationale: in this codebase "UI-only" is fictional — client auth, the role modal, and SW registration all live inside index.html, so no PM-promotable path exists that provably can't touch security behavior; and the tap is the only human checkpoint in the injection chain that can actually read code. It's ~30 seconds on Telegram a few times a week — and the minutes where Byron explains a hesitation are the highest-value mentorship in the whole design. Asymmetry kept: PM-alone one-tap Rollback to the auto-snapshotted prior deploy is always allowed (reverting to known-good never waits on anyone). Graduation criteria, published up front so it isn't paternalism: after ~10 clean promotes and once true static assets (copy, handbook, images) are split out of the index.html monolith into files with no executable surface, the PM earns autonomous promotes for that narrow real path.

---

7. Feature flags + A/B testing

Today the flag surface is literally one boolean (showCostbar). Extend meta/config.json:

flags: { "new-landing-cta": { on: true, pct: 50, salt: "a1b2", goal: "register" } }

• GET /api/user?flags=1 (already unguarded, already client-cached) returns evaluated flags: deterministic bucket = sha256(identity + salt) % 100 < pct. Same user, same variant, forever — no DB, no library.
• Results without new analytics: the platform already tracks per-user events (register, plan, exdone, proof, …) in rec.days / event logs. A nightly rollup writes per-variant counts into the flag record; the PM console Flags tab shows exposures, goal conversions per arm, and an honest "too few users to call it" label below n≈100/arm — at ~tens of users, most tests read directional, not significant, and the UI must say so rather than fake certainty. The self-hosted Plausible script gains custom events as a cross-check.
• PM can create/edit/kill flags for client UI features. Flags that select AI-prompt variants — the core coaching experience — are promote-equivalent power and go through the same needs-Byron gate as code (the Fable pass caught this as a side-door around promote controls; closed).
• Canary rollouts (the composition play, from the Fable pass): every promoted change can ship dark behind a flag, then the PM ramps it 10% → 50% → 100% through the beta segment, with automated health gates (onboarding-completion rate, JS error rate, key-event throughput per arm) and auto-rollback on regression. Bucketing, segments, event logs, and rollback all already exist — this is composition, not construction. It also resolves the autonomy tension structurally: Byron gates the code; the PM owns the rollout, with measured user behavior as the safety net. Slotted as the back half of P5.

7b. Notifications (platform gap, PM's first real project)

Out-of-app notification is today only: welcome email, invite email, Telegram-to-Byron. Proposed v1 — all reusing sendGmail + the existing weekly cron: (a) weekly board-review email digest ("your review is ready"), (b) drift nudge when quietDays ≥ 5 (the in-app cue, escalated to email, opt-out honored), (c) "your feedback shipped" email. Web push (service worker has no push handler) = phase 2. This is deliberately scoped as the PM's first end-to-end run: they spec it with the copilot, the GLM worker builds it, they A/B the nudge copy with §7, and promote it — the whole loop exercised on a real, safe feature.

---

8. The Product Charter (mission lock)

A short human-readable doc, CHARTER.md, mirrored to meta/charter.json, editable only by owner:

• Mission: AI mentorship toward user goals. Audience. Brand voice (calm, no AI-tell).
• Hard bans: illegal goods/services, adult content, gambling, medical/financial-advice claims, selling user data, dark-pattern retention, third-party ads.
• Every copilot plan, broadcast, and release brief is linted against it by flash-lite (fractions of a cent). Violations don't error — they route to needs-byron with the reason attached. Byron's veto surface stays tiny: charter edits, protected-path promotes, flagged comms, disable/delete proposals.
• Every PM action (approve, blast, meet, promote, flag change) appends to pmlog/ — an immutable audit trail visible in the Controller.
• PM account hardening is a condition of the role: the PM's Google account can email the userbase and read user PII, making it a high-value phishing target. Required: passkey/2FA on their Google account before the role is granted, anomaly flags on odd-hours actions (blast at 3am → hold + ping), and a drilled instant-revoke: one roles call removes the email from the allowlist; their 180-day token dies at the next server check.
• Rollback coherence: deploy rollback also snapshots and restores the flag/config state that shipped with that deploy, so prod code and Blob config can't be left mutually incoherent.

8b. Apprenticeship, not theater (incentive design)

The Fable pass called the sharpest risk: without accountability, the role degrades into "a human approval button between three AIs" filling use-it-or-lose-it quotas. Countermeasures, all cheap:

• One north-star metric the PM owns — proposal: weekly active mentees (users with ≥1 real event that week). Shown on their console front and center; every feature bet, blast, and meeting is framed against it. Quotas are ceilings, not targets — the metric is the target.
• A weekly 30-minute Byron–PM review of the pmlog: what shipped, what was declined, why each call was right or wrong. This ritual — not the tooling — is where the mentee actually grows, and it costs nothing to build.
• Honest instrumentation: at tens of users, A/B results are directional; the console says so explicitly rather than teaching the PM to narrate confidence over noise. Their real learning loop at this scale is qualitative — talking to users in the meetings they now have the power to book.

---

9. Cost model — worst case ≤ $37/mo

The PM's spend is structurally capped: one flat sub + one server-enforced cap. There is no action in their permission set that can create new spend categories. (The app's own user-facing AI budget — dailyBudget: 10 in config — is a separate, pre-existing line and stays admin-only.)

10. Build phases (each independently shippable)

• P1 — Role + console (~half day): 4-site role plumbing, pm in roles.json, PM console view (backlog/users/invites scoped), pmlog audit. Mentee can start triaging on day one.
• P2 — Copilot (~half day): pmplan mode, context injection, $15 cap, charter + lint.
• P3 — Comms (~half day): broadcast + segments + Meet watcher.
• P4 — Worker + deploys (~1 day): Mia executor, GLM harness, preview/promote/rollback, protected paths. Requires the $10/mo Z.ai signup (Byron, one-time).
• P5 — Flags/A-B + notifications (~1 day): flags engine, rollups, Flags tab; then notifications as the PM's first driven project.

Open items needing Byron: (1) go/no-go + which mentee; (2) Z.ai Lite signup ($10/mo) at P4; (3) approve CHARTER.md text; (4) pick the PM's north-star metric (proposal: weekly active mentees); (5) dedicated sender mailbox/alias for broadcasts; (6) confirm the PM's Google account has passkey/2FA.

---

11. Self-critique — Fable adversarial pass

Run 2026-08-23 (claude-fable-5, lenses: blast radius / incentive design / security / cost realism, plus a definitive call on promote autonomy). What it found and what changed:

• Promote tension — adjudicated. Fable ruled v1 = Byron taps every promote, no UI-only exception: the "UI-only" category is fictional while client auth lives in the index.html monolith, and the tap is the only code-literate human checkpoint in the injection chain. Adopted wholesale (§6), with PM-alone rollback kept and published graduation criteria so it reads as apprenticeship, not paternalism.
• Flags side-door — real inconsistency, closed. AI-prompt-variant flags were promote-equivalent power with no promote gate. Now needs-Byron (§7).
• Prompt-injection chain — mitigations upgraded from prompts to structure. Model-written diff summaries replaced by server-computed diffs; broker split so the GLM agent never holds the admin token; preview deploys sandboxed off prod Blob/keys as a hard P4 precondition; deploy-hygiene rules became scripted checks, not prompt text (§6).
• Social blast radius — renamed and mitigated. The likely failure is an embarrassing email, not an evil one: quality lint added, first-month blasts Byron-approved, sender moved off Byron's personal Gmail, send-time audience re-validation (§4). Meet watcher hardened to argv-exec (§4).
• Theater risk — countered with a scoreboard and a ritual. North-star metric, weekly pmlog review, quotas-as-ceilings, honest "directional-only" A/B labeling (§8b).
• Cost realism — corrected. Opus throughput restated honestly at 40–100 exchanges/month with tiered-context mitigation (§5); noted the GLM-quota "quality death spiral" risk and that Byron's review time is the real uncapped budget line. The $ cap itself was judged structurally sound.
• Bold idea — adopted. Canary rollouts with automated health gates as the back half of P5 (§7): Byron gates code, PM owns rollout, measured user behavior is the safety net.

Full critique text: https://mentor-pm.arnao.ai/critique.html (source on disk: [file:///Users/byronarnao/openclaw-gia/config/workspace/projects/mentor-app/FABLE-CRIT-pm-role.md](file:///Users/byronarnao/openclaw-gia/config/workspace/projects/mentor-app/FABLE-CRIT-pm-role.md))

---

Links