Skip to content

PiClaw v3.0.0 — Ohana

Latest

Choose a tag to compare

@piclaw-bot piclaw-bot released this 07 Sep 19:41
· 1 commit to main since this release

PiClaw v3.0.0 — “Ohana”

Family means nobody gets left behind, nobody gets somebody else’s conversation by accident, and every household member receives exactly as much authority as the clerk at the counter can prove they were issued.

The exact release range is v2.15.4..3fab87f2c17b54b43ba5e91e069be0bcf38088e1. It contains 242 commits, including 103 first-parent merged PRs plus the release and UX-gate commits, and 411 changed files, with 95,161 insertions and 1,001 deletions. VERSION and package.json are bumped to 3.0.0. Runtime dependencies are unchanged; the web build adds family and invitation browser bundles. Family mode adds database schema and offline migration machinery, but activation is deliberately explicit: single-user remains the default, and promoted family startup requires the version-five prepare/promote workflow plus domains.access.mode=family-shared.

The household register

This release builds the promoted family-shared access mode. It introduces real accounts, immutable user IDs, roles, enabled state, owned homes, owner-local session names, account-bound preferences and a separate family text shell. The old arrangement, in which one trusted local user was effectively everyone in a hat, remains the default for single-user deployments.

The new rule is simple enough to require several tables, a migration receipt and a clerk with a ruler: an administrator may manage accounts and sign-in factors, but role alone does not open another person’s conversations, avatars, memory or scheduled results. Admins get a key to the account office, not a skeleton key to the bedrooms.

Homes, roots, forks and names that belong to their owners

Sessions now have explicit root ownership. Each account can have a home root, additional roots, forks, friendly renames, archives and restores. Handles are owner-local, so two users can both have @research without the namespace behaving like a village noticeboard after rain.

Forks are captured from stable owned boundaries and persisted with owner-bound provenance. Restores are metadata-only and rehydrate later under the same ownership checks. Archive transcript download is bounded, text-only and owner-scoped; it is useful for reading an old conversation, not for smuggling the attic out through a keyhole.

Authentication with fewer communal hats

Family accounts gain per-user TOTP, multiple passkeys, labelled devices and passkeys, restricted invitations, administrator-assisted reset and offline operator recovery preparation. Invitations are browser-bound, expire, display secrets once and require explicit confirmation. Reset preserves identity, history and ownership while replacing sign-in factors; it does not reveal old seeds, because a recovery office that hands out old secrets has misunderstood both words.

The login page adapts to account policy: username-plus-code for family TOTP, passkey controls when available, hidden controls when a method is disabled, and no inventory of users or credentials in public responses.

The family shell

The family browser shell is intentionally narrower than the classic single-user app. It supports owned text conversations, account switching, My account, My sessions, family administration, personal preferences, avatars, family memory controls, prepared tasks and scheduled results. It denies unsupported rich surfaces rather than letting them wander through legacy routes with a clipboard and a convincing moustache.

Uploads, terminal/VNC, shell, workspace mutation, cross-session sends, generic add-on panes, peer ingress, direct delegate/session mutation paths and non-web polling remain denied in family mode unless they have owner-aware policy. The denial work is a feature, not an absence of imagination.

Shared memory, carefully notarised

Family memory introduces an owner-attributed publication ledger. A user can preview a text message, choose a verbatim excerpt, publish it with explicit confirmation, view shared copies and withdraw future visibility. Shared memory is attributed, bounded and retained with receipts; it is not a magical truth engine, and it does not erase copies that have already been read.

Dream work is now split by owner and family source generation, with promotion gates, retention controls, stale-run recovery and bounded provider capacity. No-tool Dream runners keep the family memory office from wandering into the tool shed at night.

Scheduled work, but only after several adults sign the form

Family scheduled execution supports paused owner-bound task grants, explicit run-once admission, internal occurrence reservation, durable handoff, result settlement, owner inspection, owner-confirmed publication, cancellation and crash/replay fences. Automatic polling and legacy scheduler activation remain disabled.

This is scheduled work in the strict civic sense: preparation does not run; admission does not prove model success; publication does not run another agent; cancellation revokes remaining authority but does not promise that a remote provider or external tool has ceased to exist. The system records what it can prove, and refuses to invent the rest, which is why it will never be elected mayor.

Migration and promotion

The new piclaw access-migration workflow inventories a single-user store, prepares a reviewed non-startable copy and promotes only a complete version-five copy into a separate family-shared database. It assigns owners, adopts handle namespaces, can capture reviewed child JSONL, revokes copied logins, pauses active tasks, quarantines ambiguous media, preserves factor material and holds legacy inputs for owner dismissal.

The source database and configuration are not edited by preview or preparation. Prepared copies carry a marker that prevents startup. Promotion requires explicit family configuration, a reviewed snapshot and stopped writers. The operator still owns backups, key material, service control and rollback. The migration machinery is less convenient than editing a marker by hand, in the same way that a bridge is less convenient than jumping.

Push, media and tool boundaries

Family Web Push subscriptions are scoped by owner and login. Presence cannot suppress another account’s notifications, and push payloads carry generic reply notices rather than conversation text.

Media reads are authorised through owned message links, and ambiguous migrated media is quarantined. Tool-output reads, store tools, session status, SSH profile calls, direct SDK builtins, add-on messaging, add-on callbacks, peer relay and delegate paths have family-mode denial or owner scoping where implemented. Every unaudited door either gained a lock or a sign explaining why the wall is currently preferable.

Documentation and operator guidance

The release adds multi-user documentation for users, administrators, migration, memory bootstrap, scheduled execution, troubleshooting and offline recovery. It also includes model pricing/workload comparison data and refreshed English, Japanese and Simplified Chinese README guides.

The guides are blunt about the trust model: family mode is for trusted households sharing one workspace. Application ownership is not filesystem confidentiality. The host operator, shared files, installed code and privileged processes remain inside the trust boundary. A family deployment can stop one account reading another’s conversation through the app; it cannot make a shared machine forget it is shared.

Security and audit notes

No runtime dependency version changes are present in the draft range. The release adds many authentication, authorisation and migration tables and routes, but the default single-user startup path is preserved unless family mode is explicitly configured and promoted. Unsupported multi-user surfaces fail closed: isolated containers return unavailable, family-denied tools and ingress paths do not silently fall back to legacy global resolution, and prepared migration copies cannot start.

The release audit uses Bun 1.4.1. Local build, fast CI and production dependency audit are green; Docker publication remains a post-tag hosted gate.

Evidence so far

  • Release head: 3fab87f2c17b54b43ba5e91e069be0bcf38088e1.
  • Version bump commit: 77985f8fe8fa6e7e2a4dcb1ffc0299d8895e5dc6; UX-gate fix commit: 3fab87f2c17b54b43ba5e91e069be0bcf38088e1.
  • Pre-bump main CI for 4bf967345aec7fb3963f892067089a650c33c479 passed: run 34152554126.
  • Local release gates passed under Bun 1.4.1: make build-piclaw (9 pass, 0 fail), make ci-fast (5176 pass, 3 skip, 0 fail, plus 23 pass and 9 pass), and bun audit --production (No vulnerabilities found, 399 packages).
  • The v3.0.0 UX prerelease gate passed on v3.0.0-ux: run 34155816638, with green workspace-and-terminal, resilience-and-compaction, and core-compose-and-sessions shards.
  • PR #1241’s web/frontend regression check passed before merge, enabling promoted family startup.
  • Final tag v3.0.0 was pushed and GitHub release publication succeeded: PiClaw v3.0.0 — Ohana.
  • Main CI passed for 3fab87f2c17b54b43ba5e91e069be0bcf38088e1: run 34156513057.
  • Docker/GHCR publication passed: run 34156513487; ghcr.io/rcarmo/piclaw:v3.0.0 resolves to index digest sha256:ca3adf1a923e2599e1afb8f5e4e997c699854eed3b2e90845ddd0f04a8279f56 with linux/amd64 and linux/arm64 manifests.
  • Release assets include the portable installers/source bundles plus one concatenated UX PDF and one data-only UX ZIP.
  • Post-publish re-check on release head 3fab87f2c17b54b43ba5e91e069be0bcf38088e1 found CI, Docker publication, UX E2E and workitems lock runs completed successfully.
  • Current open PRs not included: #1213 and #1192.

Known limits

Family mode is highly experimental. It is the first practical step towards full multi-user Piclaw for small trusted instances: households, shared labs, and machines where the people already know who is allowed near the biscuit tin. It is not a general-hosting boundary, a tenant-isolation product or a reason to hand shell-capable tools to strangers.

The longer-term “enterprise-grade” multi-user mode belongs to the far horizon, just around the corner from Mount Everest, where the roadmap thins, the air hurts, and every clipboard has an incident-response appendix. This release chooses the smaller mountain: explicit ownership, accountable admission, denied legacy doors and an operator-controlled migration path.

Single-user mode remains the default. family-shared startup requires explicit offline promotion; it is not enabled by tests, schema installation or web UI controls. Isolated-container mode is unavailable. Family mode supports a deliberately restricted browser surface; uploads, terminal/VNC, shell, broad workspace controls, generic add-on panes, peer/non-web ingress and automatic scheduling/Dream are not ordinary family user features. Application-level ownership does not isolate shared workspace files or secrets from host operators or privileged code. Migration requires stopped writers, coordinated backups and exact operator review. Physical-device proof and some full browser/recovery/device workflows still need release validation.

Upgrade

Existing single-user installations should use the normal package or container upgrade path and continue in single-user mode unless explicitly configured otherwise.

Family deployments require the documented offline procedure: stop writers, back up database/configuration/key/session state together, run preview, review every owner mapping, prepare a non-startable version-five copy, promote a separate family database under explicit family-shared configuration, install it deliberately, then restart through the host service manager. Do not edit markers, reuse a prepared copy as live state or point an older binary at a promoted family database.

The household can share the roof. The locks still need keys, receipts and someone sober enough to read the labels.

Complete PR list

  • #1137 — fix(recovery): distinguish persisted checkpoints from terminal replies
  • #1135 — data: commit model pricing and workload comparisons
  • #1136 — Add gated multi-user mode and user-store foundation
  • #1138 — Resolve request principals and expose account identity
  • #1139 — Add explicit session root ownership and authorisation
  • #1140 — Add account-bound authentication factor foundation
  • #1141 — Scope model execution identity and user memory
  • #1142 — Enforce family read scope and revoke SSE subscriptions
  • #1143 — Add owner-local session handle storage
  • #1144 — Authorise owned forks and persist deferred seeds atomically
  • #1145 — Add family account administration and safe factor removal
  • #1146 — Add restricted browser-bound family invitations
  • #1148 — Support multiple browser-bound passkeys per family account
  • #1149 — Add explicit administrator-assisted family account recovery
  • #1150 — Maintain auth expiry and support offline factor re-encryption
  • #1151 — Reconcile access-mode, authentication and runtime documentation
  • #1152 — Support owned roots, home selection and archive restore
  • #1153 — Authorise owned media and bounded archived transcript reads
  • #1154 — Deny unaudited alternate entry points in multi-user modes
  • #1155 — Scope cross-session discovery and inspection to the execution owner
  • #1156 — Scope store-tool reads and session status to active owners
  • #1157 — Persist family message authority through admission and dequeue
  • #1158 — Recover held family messages with explicit owner retry and skip
  • #1159 — Adapt login controls to public account authentication policy
  • #1160 — Add restricted invitation enrolment page with ephemeral QR setup
  • #1161 — Isolate family text shell and bind browser requests to login
  • #1162 — Discover owned held inputs and add family recovery controls
  • #1163 — Add owner-only family account Settings and capability snapshot
  • #1164 — Add owned session lifecycle Settings to the family shell
  • #1165 — Add gated family account administration Settings
  • #1166 — Add login-bound self-service authenticator enrolment
  • #1167 — Add owned passkey and device login labels
  • #1168 — Add explicit administrator device and factor revocation
  • #1169 — Add explicit administrator owned-home assignment
  • #1170 — Expose family workspace policy and enforce fixed tool ceiling
  • #1171 — Add revisioned per-account family tool restrictions
  • #1172 — Enforce family policy at direct store and discovery tools
  • #1173 — Guard family SDK builtins and tool invocation hooks
  • #1174 — Add owner-scoped appearance and response preferences
  • #1175 — Add owner-scoped validated account avatars
  • #1176 — Add owner-scoped model defaults for empty family roots
  • #1177 — Add restricted passkey invitations and admin recovery
  • #1178 — Add offline operator recovery grant preparation
  • #1179 — Prepare reviewed ownership migrations in non-startable copies
  • #1180 — Capture and import reviewed legacy child sessions
  • #1181 — Prepare explicit auth task and media migration dispositions
  • #1182 — Preserve factors and verify legacy TOTP migration into copies
  • #1183 — Hold migrated legacy inputs and document family preview workflows
  • #1184 — docs: clarify family preview guides and operator instructions
  • #1185 — feat: download owned archived transcripts in family preview
  • #1186 — fix: deny unsupported multi-user side prompt entrypoints
  • #1187 — fix: guard bundled direct model execution in multi-user modes
  • #1188 — fix: deny unsupported multi-user scheduler execution
  • #1189 — fix: guard legacy Dream entry points in multi-user modes
  • #1191 — fix: guard legacy tool output access in multi-user modes
  • #1193 — feat: prepare paused owner-bound scheduled task grants
  • #1194 — feat: add grant-bound scheduled occurrence reservations
  • #1195 — feat: persist scheduled execution handoff and owner results
  • #1196 — feat: publish scheduled results with explicit owner confirmation
  • #1197 — feat: add owner scheduled results panel and metadata list
  • #1198 — feat: add one-shot owner-bound scheduled dispatcher
  • #1199 — feat: add idempotent owner task preparation API
  • #1200 — feat: add owner paused-task preparation and revocation panel
  • #1201 — feat: recover expired scheduled handoffs without replay
  • #1202 — feat: record admitted scheduled dispatch interruptions
  • #1203 — feat: add owner-confirmed scheduled execution cancellation
  • #1204 — feat: add lifecycle-safe scheduled cancellation controls
  • #1205 — test: verify scheduled worker crash persistence and replay fences
  • #1206 — feat: admit owner-confirmed scheduled executions without replay
  • #1207 — feat: add confirmed one-shot execution to family task panel
  • #1208 — fix: bind automatic memory bootstrap to live access mode and owner
  • #1209 — fix: isolate shared family indexing from personal and legacy notes
  • #1210 — feat: add explicit owner-attributed family memory publication ledger
  • #1211 — feat: add owner-confirmed family memory HTTP controls
  • #1212 — feat: add explicit family memory browser controls
  • #1214 — feat: add attributed family memory prompt context
  • #1215 — feat: add per-owner family Dream source generations
  • #1216 — feat: add owner-confirmed Dream promotion gate
  • #1217 — feat: add no-tool owner Dream runner
  • #1218 — feat: add explicit stale Dream run recovery
  • #1219 — feat: add owner Dream run retention controls
  • #1220 — feat: add internal family Dream model admission
  • #1221 — feat: bound family Dream provider capacity
  • #1222 — feat: expose bounded family skill provenance
  • #1223 — feat: add recovery-only family startup
  • #1224 — feat: scope family tool outputs to owners
  • #1225 — Scope family Web Push recipients
  • #1226 — Group family settings navigation by scope
  • #1227 — Make family Settings panels exclusive
  • #1228 — Distinguish family account switching
  • #1229 — docs: make README a newcomer entry point
  • #1230 — Show family deployment mode
  • #1231 — Group family sessions by root
  • #1232 — Deny family SSH profile calls
  • #1233 — Deny direct multi-user session mutations
  • #1234 — Prove family delegate denial
  • #1235 — Stop non-web polling in family mode
  • #1236 — Deny family add-on messaging ingress
  • #1237 — Deny family add-on message enqueue
  • #1238 — Deny family peer relay calls
  • #1239 — Deny family add-on callbacks
  • #1240 — Scope family session handle labels
  • #1241 — feat: enable promoted family startup
  • 4bf967345aec7fb3963f892067089a650c33c479 — synchronise English, Japanese and Simplified Chinese README guides for the release candidate.
  • 77985f8fe8fa6e7e2a4dcb1ffc0299d8895e5dc6 — bump VERSION and package.json to 3.0.0.
  • 3fab87f2c17b54b43ba5e91e069be0bcf38088e1 — replace external/free-tier UX inference with a deterministic local OpenAI-compatible E2E stub.