@pikku/cli 0.12.111 → 0.12.112

package/CHANGELOG.md

@@ -1,3 +1,154 @@
+## 0.12.112
+
+### Patch Changes
+
+- 05e47cf: fix(persona): give `persona run` a singleton agent runner, so `talkTo` works
+
+  `pikku persona run` built a dev agent runner and handed it to the virtual-user
+  engine as `llm`, which covers the persona's own thinking and nothing else. The
+  `talkTo` tool does not go through that handle: `HttpPersona.converse` asks
+  `getSingletonServices()` for an `agentRunner`, and the CLI had never put one
+  there. So a persona whose scopes reached one of the app's agents threw
+  `AIProviderNotConfiguredError` on its first turn and took the whole run with
+  it, while the same project ran fine as a persona holding no agent scopes —
+  which reads as the app being broken for its privileged users rather than as a
+  missing wire in the runner.
+
+  The runner is now registered on the singleton services before the run starts.
+  Nothing else about the run changes; a project with no agents behaves exactly as
+  it did.
+
+- 05e47cf: feat(virtual-user): make a run's history readable
+
+  There was no way to ask what the virtual users had been doing. The scaffold
+  generated a way to start a run and a way to read one back by id, and
+  `VirtualUserRunStore.list()` — which takes a persona filter — had no caller at
+  all. The console's Virtual Users screen was built entirely from static meta, so
+  it could say who a persona was and what they could reach, and nothing about
+  whether anybody had ever turned them loose.
+
+  The scaffold now also generates `listVirtualUserRuns` and
+  `getVirtualUserRunSteps`, both behind the existing `virtualUser:read` scope —
+  the transcript is strictly more sensitive than the summary it belongs to, since
+  it carries the live ids and payloads the run actually sent.
+
+  The console reads the same two things through the console addon
+  (`console:getVirtualUserRuns`, `console:getVirtualUserRunSteps`) off the host's
+  own `virtualUserRunStore`, under a new `pikku:console:virtualUsers:read` scope.
+  Going through the store rather than the scaffolded RPCs means a project's runs
+  show up whether or not it turned `scaffold.virtualUser` on — wiring the store is
+  all a run has ever needed. A host with no store answers with an empty list
+  rather than an error: it has no runs, which is a true answer.
+
+  Each persona now shows its recent runs under the declaration — status, when,
+  steps and mutations, findings, disposition and seed — and opening one fetches
+  its transcript. The steps are fetched only on open, because the history is read
+  far more often than any single run is.
+
+- 05e47cf: feat(virtual-user): keep the transcript a run already produced
+
+  The engine returns `intents` and `steps` on every run — what the user set out
+  to do, and every turn it took getting there — and `VirtualUserRunOutcome` kept
+  neither. The record held counts and findings, so the one question anybody
+  actually asks of a completed run ("what did it _do_?") had no answer anywhere,
+  even though the answer had been computed and thrown away a moment earlier.
+
+  `VirtualUserRunOutcome` now carries both, and `VirtualUserRunStore` gains a
+  `steps(runId, options?)` read. Intents ride on the run record: there are a
+  handful of them and every read of the run wants them. Steps get their own
+  `virtualUserRunStep` table, because a run at a 500-step budget carries more
+  transcript than every other column together and `list()` would pay for it on
+  every row.
+
+  Three things the kysely store had to get right, all of them driver differences
+  rather than design:
+
+  - steps are inserted in chunks of 50, because a bare sqlite driver binds at
+    most 999 variables per statement and ten columns times a 500-step budget is
+    five thousand — an un-chunked insert fails on long runs, which are the
+    interesting ones;
+  - `ok` is stored as 0 or 1, since a bare driver cannot bind a boolean at all
+    and `SerializePlugin` is not installed everywhere;
+  - `response` is stored JSON-encoded, because a truncated API response usually
+    starts with a brace and `SerializePlugin` would otherwise read it back as an
+    object rather than the string the engine saw.
+
+  Completing a run that does not exist no longer writes steps: there is no
+  foreign key to refuse them and nothing would ever read or reap them.
+
+  **This adds a table to the `virtualUser` schema**, and the runtime creates
+  nothing: a database that already has `virtualUserRun` gets the store's own
+  refusal at startup until `pikku db generate` writes the migration and
+  `pikku db migrate` applies it. Landing it now costs nothing, because
+  `scaffold.virtualUser` is not yet switched on anywhere.
+
+- 05e47cf: feat(virtual-user): put each persona on its own clock
+
+  A budget says where one run stops. Nothing said how often a persona should use
+  the application, so in practice each one ran whenever somebody remembered — and
+  what actually tells you about a product is the same user coming back over a
+  fortnight.
+
+  Each persona now gets a row rather than a bigger budget. `virtualUserSchedule`
+  holds `enabled`, the disposition and goals to run with, an interval **range**,
+  and `nextRunAt`. `tickVirtualUserSchedules` acts on whichever rows are due:
+
+  ```ts
+  wireScheduler({
+    name: 'virtualUsers',
+    schedule: '0 * * * *',
+    func: tickVirtualUserSchedules,
+  })
+  ```
+
+  The tick is generated and wired by nobody, deliberately. A scaffolded
+  `wireScheduler` would start spending an application's model budget the moment
+  somebody ran `pikku all`, on a host that may not run schedulers at all. Tick
+  resolution bounds how late a due persona is, never how often it runs.
+
+  Three things it does that are easy to leave out:
+
+  - The next due time is written **before** the run is dispatched, so a tick that
+    dies halfway cannot hand the same persona to the next one. A dispatch that
+    throws waits a full interval instead of retrying every minute for a week.
+    That write is a compare-and-set against the `nextRunAt` the tick read, so it
+    is also how a tick _wins_ the persona: two processes on the same cron see the
+    same due row, and only the one whose claim lands dispatches.
+  - A persona whose previous run is still `running` is skipped, not queued. Two
+    copies of the same user acting at once is a different test, and its findings
+    do not reproduce.
+  - A run still `running` after two hours is failed. Without that, one restart
+    mid-run blocks that persona's schedule permanently — which is where the
+    stranded-record cost of not using a queue finally gets paid.
+
+  Reschedule-on-completion was the other candidate and is worse in exactly one
+  way, fatally: a crash between finishing and scheduling ends the persona forever,
+  and the evidence is an absence.
+
+  New: `VirtualUserScheduleStore` in core (with the tick, `isDue` and `nextRunAt`
+  as pure functions), `KyselyVirtualUserScheduleStore` and its own schema —
+  its own rather than a third table in `virtualUserSchema`, and owned by its own
+  store, so a project that records runs and never wants them unattended carries no
+  cadence table. `scaffold.virtualUser` gains `setVirtualUserSchedule`,
+  `listVirtualUserSchedules` and the tick, behind a new `virtualUser:schedule`
+  scope: starting a run spends money once with a caller watching, while writing a
+  schedule spends it repeatedly with nobody there.
+
+  The console's Virtual Users screen gains a **Run now** button beside a persona's
+  run history, gated on `pikku:console:virtualUsers:run`. It dispatches the
+  project's own `runVirtualUser` rather than starting a run itself, so a run the
+  application would refuse — an acted-upon persona, a non-accountable disposition
+  in production — is still refused.
+
+- Updated dependencies [3c0012c]
+- Updated dependencies [05e47cf]
+- Updated dependencies [cfd364a]
+- Updated dependencies [05e47cf]
+- Updated dependencies [05e47cf]
+- Updated dependencies [05e47cf]
+  - @pikku/core@0.12.90
+  - @pikku/kysely@0.13.21
+
 ## 0.12.111
 
 ### Patch Changes

package/console-app/assets/{abnfDiagram-N423BO3Z-Bz2Ycfpe.js → abnfDiagram-N423BO3Z-Bltf5dmS.js}

@@ -1 +1 @@
-import{m as e,t}from"./mermaid-parser.core-BtmN233C.js";import{n}from"./chunk-Y2CYZVJY-DsF7k-Jl.js";import{t as r}from"./src-CxJwpjvz.js";import"./chunk-I66GZJ75-C-Lq_UXl.js";import{n as i,r as a,t as o}from"./chunk-6Q2QTUOP-BuzItInf.js";import{t as s}from"./chunk-JWPE2WC7-DVXcaiue.js";import"./mermaid.core-37H5_HoB.js";var c=e().RailroadAbnf.parser.LangiumParser,l=n(e=>{let t=e.alternatives.map(u);return t.length===1?t[0]:{type:`choice`,alternatives:t}},`transformAlternation`),u=n(e=>{let t=e.elements.map(f);return t.length===1?t[0]:{type:`sequence`,elements:t}},`transformConcatenation`),d=n(e=>{if(e.includes(`*`)){let[t,n]=e.split(`*`);return{min:t?parseInt(t,10):0,max:n?parseInt(n,10):1/0}}let t=parseInt(e,10);return{min:t,max:t}},`parseRepeat`),f=n(e=>{let t=p(e.primary);if(!e.repeat)return t;let{min:n,max:r}=d(e.repeat);return n===0&&r===1?{type:`optional`,element:t}:{type:`repetition`,element:t,min:n,max:r}},`transformElement`),p=n(e=>{switch(e.$type){case`AbnfStringLiteral`:return{type:`terminal`,value:e.value};case`AbnfNumVal`:return{type:`terminal`,value:e.value};case`AbnfRuleName`:return{type:`nonterminal`,name:e.name};case`AbnfGroup`:return l(e.element);case`AbnfOptionalGroup`:return{type:`optional`,element:l(e.element)};default:throw Error(`Unsupported ABNF primary node: ${e.$type}`)}},`transformPrimary`),m=n(e=>({name:e.name,definition:l(e.definition)}),`transformRule`),h=n(e=>{s(e,o),e.title&&o.setTitle(e.title),e.rules.map(e=>o.addRule(m(e)))},`populateDb`),g={parser:{parse:n(e=>{o.clear(),r.debug(`[ABNF Parser] Starting Langium parse`);let n=c.parse(e);if(n.lexerErrors.length>0||n.parserErrors.length>0)throw new t(n);let i=n.value;r.debug(`[ABNF Parser] Parsed rules:`,i.rules.length),h(i),r.debug(`[ABNF Parser] Parse complete`)},`parse`),parser:{yy:o}},db:o,renderer:a,styles:i};export{g as diagram};
+import{m as e,t}from"./mermaid-parser.core-CwwjcAjz.js";import{n}from"./chunk-Y2CYZVJY-DsF7k-Jl.js";import{t as r}from"./src-BR8qR3lM.js";import"./chunk-I66GZJ75-b3yMIljX.js";import{n as i,r as a,t as o}from"./chunk-6Q2QTUOP-C_h5lS68.js";import{t as s}from"./chunk-JWPE2WC7-DVXcaiue.js";import"./mermaid.core-hmS_M4K5.js";var c=e().RailroadAbnf.parser.LangiumParser,l=n(e=>{let t=e.alternatives.map(u);return t.length===1?t[0]:{type:`choice`,alternatives:t}},`transformAlternation`),u=n(e=>{let t=e.elements.map(f);return t.length===1?t[0]:{type:`sequence`,elements:t}},`transformConcatenation`),d=n(e=>{if(e.includes(`*`)){let[t,n]=e.split(`*`);return{min:t?parseInt(t,10):0,max:n?parseInt(n,10):1/0}}let t=parseInt(e,10);return{min:t,max:t}},`parseRepeat`),f=n(e=>{let t=p(e.primary);if(!e.repeat)return t;let{min:n,max:r}=d(e.repeat);return n===0&&r===1?{type:`optional`,element:t}:{type:`repetition`,element:t,min:n,max:r}},`transformElement`),p=n(e=>{switch(e.$type){case`AbnfStringLiteral`:return{type:`terminal`,value:e.value};case`AbnfNumVal`:return{type:`terminal`,value:e.value};case`AbnfRuleName`:return{type:`nonterminal`,name:e.name};case`AbnfGroup`:return l(e.element);case`AbnfOptionalGroup`:return{type:`optional`,element:l(e.element)};default:throw Error(`Unsupported ABNF primary node: ${e.$type}`)}},`transformPrimary`),m=n(e=>({name:e.name,definition:l(e.definition)}),`transformRule`),h=n(e=>{s(e,o),e.title&&o.setTitle(e.title),e.rules.map(e=>o.addRule(m(e)))},`populateDb`),g={parser:{parse:n(e=>{o.clear(),r.debug(`[ABNF Parser] Starting Langium parse`);let n=c.parse(e);if(n.lexerErrors.length>0||n.parserErrors.length>0)throw new t(n);let i=n.value;r.debug(`[ABNF Parser] Parsed rules:`,i.rules.length),h(i),r.debug(`[ABNF Parser] Parse complete`)},`parse`),parser:{yy:o}},db:o,renderer:a,styles:i};export{g as diagram};

package/console-app/assets/architecture-TIHT7OUA-DgRqRaqo.js

@@ -0,0 +1 @@
+import"./chunk-KEIR6QF5-BICK3FdT.js";import{M as e}from"./mermaid-parser.core-CwwjcAjz.js";export{e as createArchitectureServices};