@rubytech/create-maxy-code 0.1.319 → 0.1.321

package/payload/platform/plugins/memory/references/schema-knowledge-work.md

@@ -0,0 +1,80 @@
+# Schema Reference — Knowledge Work
+
+Vertical schema for `businessType: "knowledge-work"` — the Maxy brand's knowledge workers: strategists, founders, operators, researchers, analysts.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-knowledge-work".
+
+---
+
+## Reuse the base — this vertical adds only the gaps
+
+Most of knowledge work is already in the base schema. Use the base labels, do not duplicate them:
+
+- People and orgs: `Person`, `Organization`, `Position`, `Credential`. Reporting lines are the `REPORTS_TO` edge below, not a node.
+- Work: `Task` (a `schema:Action`), `Project`, `Meeting`, `Event`, `Workflow`.
+- Concepts and content: `DefinedTerm` (concepts, skills, glossary, learnings), `Concept`, `Idea`, `CreativeWork`, `KnowledgeDocument` and `Section`.
+
+The gaps this vertical fills are: goals and OKRs, decision records, risk, and the research / citation / evidence layer. It adds those seven labels and nothing else.
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Objective | `Objective` | platform-native | `accountId`, `title`, `framework` (OKR/OGSM/V2MOM/Hoshin), `timeframe`, `status` (draft/active/achieved/missed/abandoned) |
+| KeyResult | `KeyResult` | platform-native | `accountId`, `title`, `target`, `current`, `unit`, `status` (on-track/at-risk/missed/achieved) |
+| Decision | `Decision` | `schema:CreativeWork` | `accountId`, `title`, `status` (proposed/accepted/superseded/rejected), `decision` |
+| Risk | `Risk` | platform-native | `accountId`, `statement`, `probability` (low/medium/high), `impact` (low/medium/high), `status` (open/mitigated/accepted/closed) |
+| Source | `Source` | `schema:CreativeWork` | `accountId`, `title`, `sourceType` (article/book/web/dataset/report) |
+| Finding | `Finding` | platform-native | `accountId`, `statement`, `status` (draft/validated/retracted) |
+| Hypothesis | `Hypothesis` | platform-native | `accountId`, `statement`, `status` (open/supported/refuted/assumed) |
+
+`Objective` carries the strategy framework on a `framework` discriminator rather than proliferating one label per framework: OGSM and V2MOM strategy/method tiers are `Objective` nodes distinguished by `framework`. A North-Star metric is an `Objective`-level `KeyResult`, not a separate label. A `Source` is a referenced work (a citation target), distinct from an ingested `KnowledgeDocument` whose full text lives on disk. An open research question is a `Hypothesis {status:'open'}`; an assumption is a `Hypothesis {status:'assumed'}` — the base `Question` label stays reserved for `schema:Question` FAQ content.
+
+Optional properties seen in practice: `Decision` — `context`, `consequences`, `decidedAt`; `Source` — `url`, `doi`, `datePublished`; `Finding` — `confidence`.
+
+---
+
+## Idempotency contracts
+
+MERGE keys per label:
+
+- `:Objective` — `(accountId, title)`
+- `:KeyResult` — `(accountId, objectiveTitle, title)` — child of the `:Objective` it measures
+- `:Decision` — `(accountId, title)`
+- `:Risk` — `(accountId, statement)`
+- `:Source` — `(accountId, title)`
+- `:Finding` — `(accountId, statement)`
+- `:Hypothesis` — `(accountId, statement)`
+
+---
+
+## Relationship Patterns
+
+```
+(:Objective)-[:MEASURED_BY]->(:KeyResult)
+(:Project)-[:ADVANCES]->(:Objective)
+(:Project)-[:ADVANCES]->(:KeyResult)
+(:Task)-[:ADVANCES]->(:Objective)
+(:Task)-[:ADVANCES]->(:KeyResult)
+(:Decision)-[:SUPERSEDES]->(:Decision)
+(:Risk)-[:THREATENS]->(:Objective)
+(:Risk)-[:THREATENS]->(:Project)
+(:Source)-[:AUTHORED_BY]->(:Person)
+(:Source)-[:CITES]->(:Source)
+(:Source)-[:SUPPORTS]->(:Source)
+(:Source)-[:REFUTES]->(:Source)
+(:Finding)-[:DERIVED_FROM]->(:Source)
+(:Finding)-[:DERIVED_FROM]->(:KnowledgeDocument)
+(:Finding)-[:SUPPORTS]->(:Hypothesis)
+(:Finding)-[:REFUTES]->(:Hypothesis)
+(:Task)-[:DEPENDS_ON]->(:Task)
+(:Person)-[:REPORTS_TO]->(:Person)
+(:Person)-[:RESPONSIBLE_FOR]->(:Task)
+(:Person)-[:ACCOUNTABLE_FOR]->(:Decision)
+```
+
+A `Decision` records what it decided through a `DECIDES` edge to the entity it governs (an `Objective`, a `Project`, a `Task`, or any base entity), and supersedes the decision it replaces. `Source`-to-`Source` citation uses CiTO verbs (`CITES`, `SUPPORTS`, `REFUTES`); a `Finding` is derived from its evidence (`DERIVED_FROM`, the PROV `wasDerivedFrom` relation) and bears on a `Hypothesis` (`SUPPORTS`/`REFUTES`). Task precedence uses `DEPENDS_ON` with an optional `type` property in `{FS, SS, FF, SF}` (the project-management precedence kinds). Responsibility is an edge, never a node: reporting lines are `REPORTS_TO`, and RACI assignment is `RESPONSIBLE_FOR` / `ACCOUNTABLE_FOR` / `CONSULTED_ON` / `INFORMED_OF` from a `Person` to a `Task` or `Decision` — consistent with the base doctrine that responsibility is a property of an edge, not its own node.

package/payload/platform/plugins/projects/PLUGIN.md

@@ -32,6 +32,17 @@ Explicit triggers always apply structured execution without asking:
 
 Load the relevant reference via `plugin-read` when entering a mode. Each reference describes outcomes and constraints for that mode — follow them.
 
+## Method References
+
+Beyond the four modes, the plugin carries method references for recurring needs that attach to a mode rather than defining one. Load the relevant reference via `plugin-read` when the need arises. Each one terminates in a graph write — a Task, a relationship, or a `[PROJECT:*]` note — never a free-text artefact the graph never sees.
+
+| Method | Reference | Attaches to |
+|--------|-----------|-------------|
+| Identify and engage stakeholders (Power × Interest) | `references/stakeholder-map.md` | Sprint Plan (Standard + Full) |
+| Surface and rank risks before execution | `references/risk-premortem.md` | Sprint Challenge Premise (Full) |
+| Order ready tasks by impact and effort (RICE / ICE / MoSCoW / Kano) | `references/prioritization.md` | Sprint Plan |
+| Turn a meeting transcript into decisions and tasks | `references/meeting-to-tasks.md` | Any mode |
+
 ## Creating a Project
 
 Use `project-create` to create a project atomically. One tool call creates the parent `:Project:Task` node, all child work items, dependency relationships (`BLOCKS`), and entity relationships (`RAISED_BY`, `AFFECTS`) in a single transaction.

package/payload/platform/plugins/projects/references/meeting-to-tasks.md

@@ -0,0 +1,34 @@
+# Meeting to Tasks
+
+A method for turning a meeting transcript into tracked project records: decisions captured as notes, action items created as child tasks. A client engagement generates meetings, but a transcript on its own is inert — the decisions and commitments in it are not in the graph, so nothing reminds anyone to act on them. This converts the conversation into the same structures the rest of the plugin uses.
+
+## Method: separate decisions from actions
+
+Read the transcript and pull out two distinct kinds of content. Keep them separate — they terminate differently.
+
+- **Decisions** — things the meeting settled. A choice made, a direction agreed, a scope change, a problem identified. These are facts about the project's history.
+- **Action items** — things someone committed to do. Each has an owner (even if implicit) and an outcome. These are future work.
+
+Discard everything else. Discussion that led nowhere, restated context, and small talk do not become records. The test for an action item is whether someone is expected to do something as a result; the test for a decision is whether the project's state changed because of it.
+
+For each action item, capture who owns it and what "done" looks like, so it can be created as a real task rather than a vague reminder.
+
+## Graph termination
+
+The transcript itself is never the deliverable — the records it produces are.
+
+- **Decisions become project notes.** Append each to the project with `project-update` using the matching lifecycle format: a settled direction or scope change as `[PROJECT:CHANGE] {what changed} — Reason: {why}`, a problem raised as `[PROJECT:ISSUE] {description} — Impact: {assessment}`, a general decision as a `[PROJECT:PHASE]` note. These land in the project's searchable history.
+- **Action items become child tasks.** Create each with `work-create`, naming the owner in the task description (there is no assignee relationship — the owner lives on the task itself). Attach the task to the project via `work-relate` (`PART_OF`, passing the project `taskId`). If the transcript names who requested the action, link that person with `RAISED_BY`; link any affected entity with `AFFECTS`. The action then flows through `work-ready` and execution like any other task.
+
+After processing a transcript, `project-get` shows new notes for the decisions and new child tasks for the action items. A transcript that produces neither was not processed — it was only read.
+
+## Wiring
+
+This method is invokable in any mode, not tied to a single sprint phase — meetings happen throughout a project's life. Load it via `plugin-read` whenever a transcript is pasted into a project conversation, or when the operator asks to turn meeting notes into tasks. If the meeting belongs to no existing project, create or identify the project first so the notes and tasks have a parent.
+
+## When to Use
+
+- A meeting transcript pasted into a project conversation.
+- "Turn these notes into tasks."
+- "What did we agree in that call?"
+- "Capture the action items from the client meeting."

package/payload/platform/plugins/projects/references/prioritization.md

@@ -0,0 +1,43 @@
+# Prioritization
+
+A method for ordering a project's tasks when every one looks important and dependency edges alone do not decide the sequence. `BLOCKS` relationships say what *must* come before what; they say nothing about what *should* come first among tasks that are all ready. This reference supplies a named framework for that choice and reflects the result in how tasks are created and noted — no schema change.
+
+## When dependency order is not enough
+
+`work-ready` returns the set of tasks with no unresolved blockers. When that set has one item, the choice is made. When it has many, the operator needs a way to rank them. Pick one framework below to fit the project; do not mix them within a single project.
+
+### RICE
+
+Score each task on Reach (how many people or cases it touches), Impact (how much it moves the outcome), Confidence (how sure you are of the first two), and Effort (how much work it takes). Rank by `(Reach × Impact × Confidence) ÷ Effort`. Use RICE when tasks vary widely in both benefit and cost and you want a single comparable number.
+
+### ICE
+
+A lighter RICE: score Impact, Confidence, and Ease (the inverse of effort), each on a simple scale, and rank by their product. Use ICE for a quick ranking when full RICE scoring is more precision than the project warrants.
+
+### MoSCoW
+
+Sort tasks into Must have, Should have, Could have, and Won't have (this time). Use MoSCoW when the project has a fixed deadline and the real question is what to drop, not what to score — it makes the cut line explicit.
+
+### Kano
+
+Classify each task by how it affects satisfaction: basic expectations (their absence causes complaints, their presence is unremarkable), performance features (more is better), and delighters (unexpected, disproportionately appreciated). Use Kano when the project is about a client-facing result and you are deciding where extra effort earns the most goodwill.
+
+## Graph termination
+
+Prioritization changes the order work is created and started, and records the decision — it never leaves a free-standing ranked list.
+
+- **Create or order tasks to reflect the ranking.** When building the project, create the higher-ranked work items first so they surface earlier; for an existing project, the ranking decides which ready task is started next via the normal `work-ready` flow.
+- **Record the method and the resulting order as a note.** Append to the project with `project-update`, e.g. `[PROJECT:PHASE] Prioritized via RICE — top three: site survey, supplier quotes, deposit invoice`. This makes the reasoning auditable later and visible in `project-get`.
+
+No new property or relationship is introduced — priority lives in creation order and the lifecycle note, not a schema field.
+
+## Wiring
+
+This method runs inside the Plan phase of `sprint.md`. Load it via `plugin-read` when a project has many tasks and dependency edges do not settle the sequence. It pairs with `stakeholder-map.md` in the same phase: stakeholder power often informs Impact.
+
+## When to Use
+
+- A Plan phase where many tasks are ready and the order is unclear.
+- "Everything feels urgent — what do we do first?"
+- "We can't do all of this before the deadline — what makes the cut?"
+- A client project where you are deciding where to spend the extra effort.

package/payload/platform/plugins/projects/references/risk-premortem.md

@@ -0,0 +1,34 @@
+# Risk Pre-Mortem
+
+A forward-looking method for surfacing what could go wrong before a project starts, ranking each risk, and turning the serious ones into either a recorded issue or a mitigation task. Investigation mode handles problems after they happen; this is the opposite — it finds problems while they are still cheap to prevent. The Challenge Premise phase of a Full sprint asks whether the work is right but names no method for the risks; this supplies it.
+
+## Method: imagine it already failed
+
+The pre-mortem inverts the usual question. Instead of "what might go wrong?", assume the project has already failed and ask: "it is six months from now and this went badly — what happened?" Working backwards from an assumed failure surfaces risks that forward optimism hides, because the team is now explaining a failure rather than defending a plan.
+
+Generate the list of failure causes, then rank each one on two axes:
+
+- **Likelihood** — how probable is this, given what you know? Low / Medium / High.
+- **Impact** — if it happens, how much does it hurt the project? Low / Medium / High.
+
+The product of the two sets priority. A High × High risk is addressed before execution starts. A Low × Low risk is noted and left. The middle band is where judgement applies — a low-likelihood, high-impact risk (a key supplier folding) often deserves a mitigation even though it probably will not happen.
+
+## Graph termination
+
+Every risk worth surfacing terminates in the graph — never as chat-only text.
+
+- **Serious risks become a recorded issue.** For each High-impact risk, append a note to the project with `project-update` in the issue format: `[PROJECT:ISSUE] {risk description} — Impact: {likelihood × impact assessment}`. This lands it in the project's searchable lifecycle history.
+- **Risks you will act on become a mitigation Task.** Where a risk warrants concrete preventive work, create it with `work-create` and attach it to the project via `work-relate` (`PART_OF`, passing the project `taskId`). The mitigation then flows through the normal `work-ready` / execution path like any other task.
+
+A pre-mortem that produces only a verbal warning has failed its own method. The test: after running it, `project-get` shows `[PROJECT:ISSUE]` notes or related mitigation Tasks. If it shows neither, nothing was actually captured.
+
+## Wiring
+
+This method runs inside the Challenge Premise phase of `sprint.md` (Full tier), before Lock Execution. Load it via `plugin-read` once the scope is agreed but execution has not begun — mitigations identified here change the locked task list. It can also run standalone before any significant project when the operator asks what could go wrong.
+
+## When to Use
+
+- A Full sprint Challenge Premise phase, before the plan is locked.
+- "What could go wrong with this?"
+- "Before we commit, what are the risks?"
+- A high-stakes project where a preventable failure would be expensive.

package/payload/platform/plugins/projects/references/sprint.md

@@ -40,6 +40,8 @@ Understand the project scope: what are the deliverables, who are they for, what'
 
 Check for prior learnings: call `memory-search` with a description of the project to surface relevant learnings from past similar work. If learnings exist, factor them into the plan — adjust timelines, flag known risks, apply lessons learned.
 
+When the project has more than one interested party, map them with `references/stakeholder-map.md`. When many tasks are ready and dependency order does not settle the sequence, order them with `references/prioritization.md`. Load either via `plugin-read`.
+
 ### Execute
 
 Work through the child tasks in dependency order. Before starting each task, check `work-ready` to confirm no blockers or AFFECTS conflicts. Append progress notes as work progresses. If a blocker is discovered mid-execution, create a new child task for it and link via `BLOCKS`.
@@ -73,7 +75,7 @@ Mark the parent Task complete with `[PROJECT:COMPLETE]`.
 
 ### Plan
 
-Same as Standard Plan, but more thorough: map all stakeholders, identify risks, estimate timeline for each work item, and define acceptance criteria for every deliverable.
+Same as Standard Plan, but more thorough: map all stakeholders (use `references/stakeholder-map.md`), identify risks, estimate timeline for each work item, and define acceptance criteria for every deliverable. Order ready work with `references/prioritization.md` when the sequence is not obvious.
 
 ### Challenge Premise
 
@@ -85,6 +87,8 @@ Before locking in the execution plan, challenge the scope:
 
 Surface any concerns and resolve them before proceeding.
 
+Run a pre-mortem to surface what could go wrong before the plan is locked: load `references/risk-premortem.md` via `plugin-read`. Mitigations identified here change the locked task list, so run it before Lock Execution.
+
 ### Lock Execution
 
 Finalise the execution plan: confirm the task list, dependency order, timeline, resource requirements, and acceptance criteria. This is the agreement — Phase 6 (Plan Conformity) will check the outcome against this.

package/payload/platform/plugins/projects/references/stakeholder-map.md

@@ -0,0 +1,43 @@
+# Stakeholder Map
+
+A method for identifying the people a project affects or depends on, and deciding how to engage each one. The Plan phase of a Standard or Full sprint names "multiple stakeholders" but gives no way to find them or decide who needs what. This reference supplies that method and terminates in graph relationships, not a loose list.
+
+Use this whenever a project has more than one interested party — a client plus their finance team, a landlord plus tenants, a partner plus the people who sign off the work. A project with a single decision-maker does not need it.
+
+## Method: Power × Interest
+
+Place each stakeholder on two axes:
+
+- **Power** — how much influence they have over whether the project succeeds. Can they approve it, fund it, block it, or redirect it?
+- **Interest** — how much the project's outcome affects them. Will they feel the result day to day, or is it peripheral to them?
+
+Each stakeholder lands in one of four quadrants. Each quadrant has a default engagement posture:
+
+| Quadrant | Power | Interest | Engagement posture |
+|----------|-------|----------|--------------------|
+| Manage closely | High | High | Involve in decisions, update frequently, resolve their concerns first |
+| Keep satisfied | High | Low | Brief enough to keep onside, do not overload — they disengage if flooded |
+| Keep informed | Low | High | Regular updates, listen for early warnings — they often see problems first |
+| Monitor | Low | Low | Minimal contact, light-touch updates only when the outcome touches them |
+
+Work through the project and ask, for each person or group: who decides, who pays, who does the work, who is affected by the result, who could block it. Place each one. The grid surfaces two failure modes a flat list hides: a high-power stakeholder being treated as peripheral, and effort spent over-communicating with someone who has neither power nor interest.
+
+## Graph termination
+
+A stakeholder map is not done until it lands in the graph against the project.
+
+- **Record each stakeholder as a node related to the project.** If the person already exists, find them via `memory-search`; otherwise create them through the normal entity path. Then relate them to the project Task with `work-relate`: use `RAISED_BY` for the person who requested or sponsors the project, and `AFFECTS` for people or entities the project's outcome changes. Pass the project `taskId` from `project-create`/`project-get` and the stakeholder `elementId` from `memory-search`.
+- **Record the engagement decision as a note.** Append the posture per quadrant to the project with `project-update`, e.g. `[PROJECT:PHASE] Stakeholders mapped — 2 manage-closely (client, surveyor), 1 keep-informed (tenant); client concerns resolved first`.
+
+Do not leave the map as chat-only text. If a stakeholder is worth naming, the relationship is worth writing — that is what lets `project-get` and conflict detection (`AFFECTS`) see them later.
+
+## Wiring
+
+This method runs inside the Plan phase of `sprint.md` (Standard and Full tiers). Load it via `plugin-read` when a project has more than one interested party. Full tier maps all stakeholders; Standard tier maps the ones with high power or high interest and monitors the rest.
+
+## When to Use
+
+- A project Plan phase where "who are the deliverables for" has more than one answer.
+- "Who do we need on side for this?"
+- "Make sure we keep everyone in the loop on the refit."
+- Before a project where one party could block progress and has not yet been engaged.

package/payload/platform/scripts/installer-device-verify.sh

@@ -235,6 +235,44 @@ REMOTE
     continue
   fi
 
+  # Step 2b — base toolchain command-presence audit. An independent check of
+  # actual PATH state (not an install log): a pre-existing box that never
+  # re-runs the installer keeps the tools missing with no log line, so this
+  # greps the live binaries directly. python, python3, pip, and file must all
+  # resolve. Linux-only: Homebrew supplies python3/pip3 but not the bare
+  # python/pip aliases on darwin, so a laptop install is expected to lack them
+  # and the audit skips rather than false-failing a Mac in the manifest.
+  TOOLCHAIN_CHECK=$(cat <<'REMOTE'
+set -uo pipefail
+OS=$(uname -s)
+if [[ "$OS" != "Linux" ]]; then
+  echo "toolchain-check skipped reason=non-linux os=$OS"
+  exit 0
+fi
+MISSING=""
+for c in python python3 pip file; do
+  command -v "$c" >/dev/null 2>&1 || MISSING+="$c "
+done
+if [[ -n "$MISSING" ]]; then
+  echo "toolchain-missing: ${MISSING% }"
+  exit 1
+fi
+echo "toolchain-ok python python3 pip file all on PATH"
+exit 0
+REMOTE
+)
+
+  set +e
+  run_ssh "$TARGET" "$PASS" "$TOOLCHAIN_CHECK" >>"$SUMMARY_LOG" 2>&1
+  TOOLCHAIN_RC=$?
+  set -e
+
+  if [[ $TOOLCHAIN_RC -ne 0 ]]; then
+    echo "FAIL  $NAME — base toolchain command missing (rc=$TOOLCHAIN_RC, see $SUMMARY_LOG)" | tee -a "$SUMMARY_LOG"
+    FAILED=1
+    continue
+  fi
+
   # Step 3 — standing Samba socket audit (Task 755). Reconcile the *actual*
   # listening sockets against the bind invariant, independent of any install
   # log, so this catches a drifted or re-opened box as well as a fresh

package/payload/platform/services/claude-session-manager/dist/http-server.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"http-server.d.ts","sourceRoot":"","sources":["../src/http-server.ts"],"names":[],"mappings":"AAsBA,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAA;AAa3B,OAAO,EAgBL,KAAK,SAAS,EAEf,MAAM,kBAAkB,CAAA;AAsBzB,OAAO,KAAK,EAAE,SAAS,EAAyB,MAAM,iBAAiB,CAAA;AAEvE,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAA;AAC1D,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAA;AAC3D,OAAO,EAAqB,KAAK,cAAc,EAAE,MAAM,uBAAuB,CAAA;AAC9E,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAA;AACtD,OAAO,EAAE,mBAAmB,EAAE,MAAM,4BAA4B,CAAA;AAgFhE,eAAO,MAAM,kBAAkB,QAA2B,CAAA;AAS1D,eAAO,MAAM,4BAA4B,QAAS,CAAA;AAIlD,MAAM,WAAW,QAAS,SAAQ,IAAI,CAAC,SAAS,EAAE,gBAAgB,GAAG,SAAS,CAAC;IAC7E;;qEAEiE;IACjE,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,OAAO,EAAE,SAAS,CAAA;IAClB,WAAW,EAAE,MAAM,CAAA;IACnB,iBAAiB,EAAE,MAAM,CAAA;IACzB,kBAAkB,EAAE,WAAW,CAAA;IAC/B,eAAe,EAAE,aAAa,CAAA;IAC9B;kFAC8E;IAC9E,cAAc,EAAE,cAAc,CAAA;IAC9B;;gFAE4E;IAC5E,cAAc,EAAE,cAAc,CAAA;IAC9B;;;6BAGyB;IACzB,mBAAmB,CAAC,EAAE,mBAAmB,CAAA;IACzC;;gFAE4E;IAC5E,gBAAgB,CAAC,EAAE,MAAM,CAAA;CAC1B;AAwGD,wBAAgB,eAAe,CAAC,aAAa,EAAE,MAAM,EAAE,YAAY,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,EAAE,CAEpG;AAgBD,wBAAgB,oBAAoB,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAE1D;AAUD,wBAAgB,2BAA2B,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,MAAM,CAMvE;AAMD,wBAAgB,gBAAgB,CAC9B,SAAS,EAAE,MAAM,GAAG,IAAI,EACxB,OAAO,EAAE,MAAM,EACf,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,MAAM,GAAG,IAAI,GACtB,MAAM,CAER;AAkCD,wBAAgB,0BAA0B,CAAC,KAAK,EAAE,MAAM,EAAE,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAe5F;AAwJD;;;kEAGkE;AAClE,MAAM,MAAM,OAAO,GAAG,IAAI,GAAG;IAC3B,2BAA2B,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;IACpD;;;+CAG2C;IAC3C,sBAAsB,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAChD,CAAA;AAmBD,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,GAAG,OAAO,CAwwEpD"}
+{"version":3,"file":"http-server.d.ts","sourceRoot":"","sources":["../src/http-server.ts"],"names":[],"mappings":"AAsBA,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAA;AAa3B,OAAO,EAgBL,KAAK,SAAS,EAEf,MAAM,kBAAkB,CAAA;AAsBzB,OAAO,KAAK,EAAE,SAAS,EAAyB,MAAM,iBAAiB,CAAA;AAEvE,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAA;AAC1D,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAA;AAC3D,OAAO,EAAqB,KAAK,cAAc,EAAE,MAAM,uBAAuB,CAAA;AAC9E,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAA;AACtD,OAAO,EAAE,mBAAmB,EAAE,MAAM,4BAA4B,CAAA;AAgFhE,eAAO,MAAM,kBAAkB,QAA2B,CAAA;AAS1D,eAAO,MAAM,4BAA4B,QAAS,CAAA;AAIlD,MAAM,WAAW,QAAS,SAAQ,IAAI,CAAC,SAAS,EAAE,gBAAgB,GAAG,SAAS,CAAC;IAC7E;;qEAEiE;IACjE,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,OAAO,EAAE,SAAS,CAAA;IAClB,WAAW,EAAE,MAAM,CAAA;IACnB,iBAAiB,EAAE,MAAM,CAAA;IACzB,kBAAkB,EAAE,WAAW,CAAA;IAC/B,eAAe,EAAE,aAAa,CAAA;IAC9B;kFAC8E;IAC9E,cAAc,EAAE,cAAc,CAAA;IAC9B;;gFAE4E;IAC5E,cAAc,EAAE,cAAc,CAAA;IAC9B;;;6BAGyB;IACzB,mBAAmB,CAAC,EAAE,mBAAmB,CAAA;IACzC;;gFAE4E;IAC5E,gBAAgB,CAAC,EAAE,MAAM,CAAA;CAC1B;AAgHD,wBAAgB,eAAe,CAAC,aAAa,EAAE,MAAM,EAAE,YAAY,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,EAAE,CAEpG;AAgBD,wBAAgB,oBAAoB,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAE1D;AAUD,wBAAgB,2BAA2B,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,MAAM,CAMvE;AAMD,wBAAgB,gBAAgB,CAC9B,SAAS,EAAE,MAAM,GAAG,IAAI,EACxB,OAAO,EAAE,MAAM,EACf,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,MAAM,GAAG,IAAI,GACtB,MAAM,CAER;AAkCD,wBAAgB,0BAA0B,CAAC,KAAK,EAAE,MAAM,EAAE,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAe5F;AAwJD;;;kEAGkE;AAClE,MAAM,MAAM,OAAO,GAAG,IAAI,GAAG;IAC3B,2BAA2B,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;IACpD;;;+CAG2C;IAC3C,sBAAsB,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAChD,CAAA;AAmBD,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,GAAG,OAAO,CA4xEpD"}

package/payload/platform/services/claude-session-manager/dist/http-server.js

@@ -30,13 +30,13 @@ import { mergeTarget, isMultiTarget, targetKinds } from './channel-targets.js';
 import { randomUUID } from 'node:crypto';
 import { execFileSync } from 'node:child_process';
 import { buildRcChildEnv, reapplyAdminLevers } from './rc-daemon.js';
-import { isEffortLevel, isPermissionMode } from '../../../lib/models/dist/index.js';
+import { isEffortLevel, isPermissionMode, SONNET_MODEL } from '../../../lib/models/dist/index.js';
 import { spawnClaudeSession, stopSession, writeInputToPty, isLive, onPtyExit, livePtyCount, liveSessionIds, getPtyTrackerForTests, livePidForSession, priorExitedCountForSession, PERMISSION_MODES, openFdCount, registerRcSpawnPty, } from './pty-spawner.js';
 import { writeScopeRecord, removeScopeRecord } from './scope-record.js';
 import { writeReseatMarker, resolveReseatChain, clearReseatMarker } from './reseat-ledger.js';
 import { getScopeMainPid, defaultProcessSignals, defaultSystemctlRunner } from './systemd-scope.js';
 import { readSidecar, updateSidecar, appendBridgeId, writeSidecar } from './session-sidecar.js';
-import { resolveSettingsPermissionMode } from './settings-permission-mode.js';
+import { resolveSettingsPermissionMode, resolveSettingsModel, resolveSettingsEffort } from './settings-permission-mode.js';
 import { emitRcLife } from './rc-life.js';
 import { readJsonlSession } from './jsonl-enumerator.js';
 import { watchInputSubmission, countUserEntries } from './input-postcondition.js';
@@ -739,9 +739,15 @@ export function buildHttpApp(deps) {
         const specialist = typeof body.specialist === 'string' && /^[A-Za-z0-9_-]{1,64}$/.test(body.specialist)
             ? body.specialist
             : undefined;
-        const model = typeof body.model === 'string' && /^[A-Za-z0-9._-]{1,64}$/.test(body.model)
-            ? body.model
-            : undefined;
+        // Task 956 — public sessions are pinned to Sonnet 4.6 (operator decision:
+        // admin-only Bypass/Opus; public stays Sonnet + fail-closed dontAsk). The
+        // role==='public' force is the chokepoint covering every public spawn
+        // (webchat + WhatsApp); other roles keep their body-supplied model.
+        const model = role === 'public'
+            ? SONNET_MODEL
+            : typeof body.model === 'string' && /^[A-Za-z0-9._-]{1,64}$/.test(body.model)
+                ? body.model
+                : undefined;
         const initialMessage = typeof body.initialMessage === 'string' && body.initialMessage.length > 0
             ? body.initialMessage
             : undefined;
@@ -1190,6 +1196,11 @@ export function buildHttpApp(deps) {
                     model: enriched.model,
                     displayName: enriched.displayName,
                     titleSource: enriched.titleSource,
+                    // Task 956 — context-usage source (latest-turn token sum) + the
+                    // settings-resolved effort the session launched under, for the
+                    // /chat read-only params row.
+                    usedTokens: enriched.usedTokens,
+                    effortLevel: resolveSettingsEffort(deps.claudeConfigDir),
                 };
             }
         }
@@ -2202,6 +2213,13 @@ export function buildHttpApp(deps) {
         // Task 928 — when the fork carries a picked mode, the argv flag governs (not
         // settings.json), so the lifeline and the sidecar must report the picked mode.
         const effectiveRcPermissionMode = forkFromSessionId !== null && reseatPermissionMode ? reseatPermissionMode : settingsPermissionMode;
+        // Task 956 — the model/effort the rc session actually runs under. A non-fork
+        // admin spawn carries no --model/effort argv, so the binary reads
+        // settings.json (pinned to Opus/medium by the rc-daemon); a fork rides its
+        // picked values. Surfaced on the lifeline so the admin-param audit can assert
+        // model=claude-opus-4-8[1m] effort=medium without reconstructing the argv.
+        const effectiveRcModel = forkFromSessionId !== null && reseatModel ? reseatModel : resolveSettingsModel(deps.claudeConfigDir);
+        const effectiveRcEffort = forkFromSessionId !== null && reseatEffort ? reseatEffort : resolveSettingsEffort(deps.claudeConfigDir);
         // Step 2 — the exact claude argv (the inner command). The systemd-run
         // wrap is composed by the spawnPty adapter; logging the inner argv
         // here is enough for an operator to reproduce by hand. The wrapped
@@ -2211,7 +2229,7 @@ export function buildHttpApp(deps) {
         // argv (the trailing `initialMessage`, else 0) so a future oversized positional
         // is visible without reconstructing it from the full argv dump.
         const positionalBytes = initialMessage ? Buffer.byteLength(initialMessage, 'utf8') : 0;
-        deps.logger(`[rc-spawn] op=argv unitToken=${unitToken} cwd=${deps.spawnCwd} permissionMode=${effectiveRcPermissionMode} positionalBytes=${positionalBytes} argv=${JSON.stringify([deps.claudeBin, ...argv])}`);
+        deps.logger(`[rc-spawn] op=argv unitToken=${unitToken} cwd=${deps.spawnCwd} permissionMode=${effectiveRcPermissionMode} model=${effectiveRcModel ?? 'unset'} effort=${effectiveRcEffort ?? 'unset'} positionalBytes=${positionalBytes} argv=${JSON.stringify([deps.claudeBin, ...argv])}`);
         emitRcLife(deps.logger, 'argv', 'rc-spawn', 'node-pty', rcLifeMode, unitToken, {
             cwd: deps.spawnCwd,
             argv: JSON.stringify([deps.claudeBin, ...argv]),