Release Notes

Release entries appear newest first. Older entries stay here for reference.

v0.8.4 — 2026-10-26

New features

Architect generation and intake

• Context-driven multi-page generation combines written instructions and accepted attachments. Follow-up builds continue the existing named app and preserve accepted source when planning, model validation or compilation fails.
• Optional ChatGPT account connections complement API-key LLM vendors. Connection management, model selection and generation use the shared OAuth foundation without enabling external account login for Pharos apps.
• Mixed-folder intake accepts context documents, CSV data and images together. Automatic CSV import creates data tables, normalizes matching labels and treats repeat imports idempotently. Data-bound views can associate imported records with their images.
• Image intake supports up to 1,000 images, with a 2 MiB per-image limit and batches of ten. Uploaded assets remain associated with the task and are included through app-relative source assets.
• Editable app IDs can be renamed from Recent builder tasks. Renaming keeps the project, context and preview records, updates source exports and subsequent builds, and safely rebases restored snapshots to the current identity. App-bound sessions and social connections require sign-in again after renaming.
• One shared source-import form accepts an app folder or ZIP, TAR, TAR.GZ or TGZ archive. Early size/file checks reject oversized sources before upload; imported YAML and JSON database contracts retain their authored format.

Visual editing

• Shared editable grouping gives page rows, element containers and native controls consistent selection targets across generated, imported and shipped interfaces.
• Element and group movement supports placement within containers and beside other elements while retaining the current preview view. Pointer Events and pointer capture replace mouse-only drag tracking.
• The property editor supports text and mouse-over text, icon selection/removal and pixel sizing, background colors, synchronized color/hex inputs, border opacity and shadows. Colors, images and borders share one panel, with consistent Apply controls.
• Preview authentication, navigation, assets and popups remain within the isolated app preview. Preview accounts support admin and user testing; these accounts are not production account provisioning.

Declarative CRM

• Declarative schemas, queries, actions and UI support contacts, organizations, leads, notes, activity, follow-ups and linked records.
• CRM capabilities include validated CRUD, database-backed search/filtering/ordering, policy and owner/tenant boundaries, transactional history writes, revision-guarded edits and declared archive/delete behavior. Schemas, migrations, permissions and templates define record types and presentation.
• Generated admin/API surfaces and app-owned HTMX fragments use the same framework services. See Declarative CRM for the authoring guide and links to transaction, validation and UI contracts.

Social connections

• Social connections provide scoped provider credentials, encrypted storage and background collection jobs through authenticated adapters and configuration.
• Persistent browser sign-in connections retain their scoped profile across restarts. Reconnect reuses the saved profile; disconnect clears the saved sign-in.
• Collection retains source evidence and distinguishes partial or unavailable access from an empty successful result. Publication uses declared permissions and validation rules.

Fixes and refinements

• Removed binary-size budgets from native build and release verification. Distribution size no longer blocks a server release.
• Windows SQLite connections use their supported file-locking mode instead of requesting shared-WAL coordination that is unavailable in the Windows I/O backend.
• App builds on Windows write portable ownership paths so generated artifacts pass the same boundary checks as Unix builds.
• Architect upgrades remove the obsolete task-event restriction without changing existing records or earlier migration checksums. Constraint failures are reported separately from actual database contention.
• Architect task lists respect the logged-in user. Builder accounts can access their LLM settings; account administration remains role-gated.
• Build failures remain visible, and accepted-context history and expandable audit entries make generation outcomes easier to inspect. Readable errors show the error code, message and available correlation ID instead of raw error envelopes.
• Follow-up request classification ignores embedded existing-source reference metadata, so ordinary app edits do not acquire unrelated commerce prerequisites.
• Source import, project deletion, stale-plan handling and preview project registration no longer leave valid editable projects stranded behind unavailable actions.
• Saved typography, layout, icon and style changes persist across refreshed fragments and reopened editors. Exported CSS excludes internal preview-edit comments.
• Preview toolbars stay above the app without covering its controls. Shared rendering paths keep menus, import controls and editor panels consistent.
• Media and extraction models use separate configurable roots; model binaries no longer belong inside the Architect app source bundle.
• UCAL service initials ignore parentheses, and managed service cards place the service name above price and duration.

Connection and upgrade requirements

• ChatGPT access depends on the connected account's model availability and provider limits. A successful sign-in does not guarantee access to every model.
• Social platforms may expire sessions, require verification or restrict collection. Browser sign-in is separate from provider API authorization; API connectors require the relevant registration and permissions. A partial rendered feed is not a complete scrape, and a connection alone does not guarantee access to every resource.
• Existing populated apps retain their configured database, external media, credentials and migration history. Back up external configuration and data before upgrading.
• YAML database contracts compile to JSON artifacts; imported JSON contracts remain supported.

Published artifacts

Runtime downloads include the Linux x86_64 GNU Debian package and tarball, macOS Intel and ARM64 installers, and the Windows x86_64 ZIP. Architect, Dev Docs and UCAL have separate app archives. SHA256SUMS-0.8.4.txt covers the complete public asset set. Platform validation and publication evidence accompany the release.

Packaged apps in the base release

The Debian package includes Todo List, Commerce SPA, Dynamic App and Static App, together with runtime helpers and source examples. Architect, Dev Docs and UCAL are separately distributed apps; they are not installed by the base Debian package.

v0.8.3 — 2026-10-09

New Features

Architect

• Accepts multiple context files in one build request. The task keeps each accepted file for later review.
• Accepted context history shows the text and attachments used in successive builds of an app.
• Follow-up text requests can change an existing generated app. For example, a user can add a dashboard field or move a selected page element, then review the updated preview.
• The visual editor can add form rows, containers, text, and controls through an organized element menu.
• Drag-and-drop editing moves an element to a new position. Holding Alt or Option while dragging places it inside another element.
• Undo and redo restore recent visual edits. Use Command or Control+Z to undo, and add Shift to redo.
• Element editing reaches nested text and icons. Saved changes remain in the app when the user reopens its preview.
• Generates backend-independent apps that inherit its configured database backend. Generated apps keep the same logical schema when you choose another supported backend.
• Data-model edits convert stored field values alongside the schema change. Conversion checks reject incompatible values before changing existing records.

Database

• Human-readable YAML database contracts support reusable declarations through anchors and aliases. App builds validate and compile them to JSON; Architect generates and exports YAML source while runtime database loading remains JSON-only.
• Database-backed apps use one logical database interface with all supported primary backends. Choose the backend through configuration without rewriting app queries or migrations. Primary backends supported are: SQLite, PostgreSQL, MySQL, or MongoDB
• Portable database declarations cover entities, indexes, uniqueness, foreign keys, checks, and historical data updates. Each backend implements the same declared rules.
• Logical backups and restores support every primary backend. Restore checks validate the schema and records before committing changes.

Included changes

• The context entry grows with longer instructions and scrolls when it reaches its height limit. Selected files appear beside the context label before the build starts.
• UCAL booking and business management, storefront carts and orders, and Architect project storage use the shared database contract.
• In-memory JSON working views support calculations and rendering. Guarded transactions persist changed records without exporting and importing the whole database for each interaction.
• Startup readiness checks verify the declared physical schema before serving database-backed apps.
• Separate runtime components support cached builds of unchanged helpers and database drivers.

Database configuration

• New apps use the configured backend. Moving an existing populated app to another backend requires an explicit data export, import, and verification before accepting writes.
• Redis retains its existing role as an optional cache. It does not replace the configured primary database.

Fixes and refinements

Database and deployment

• Commerce upgrades recover a missing store from its recorded owner membership, preserve existing ownership, and reject ambiguous ownership without changing historical migrations.
• Populated SQLite schema adoption installs missing nullability constraints and both column and table checks while preserving historical checks and existing records; repeat application retains the migration ledger.
• Menu SPA recognizes its verified historical schema-file checksum during logical contract adoption without replaying catalog seeds.
• Runtime deployment migrates only Debian-owned apps. External apps use their updated staged bundles for migration, avoiding attempts to migrate older installed contracts with a newer runtime.
• Runtime and app upgrades retain configured database connections, namespaces, and data locations so separate apps cannot be redirected into one global database during migration.

Runtime and Commerce

• Browser navigations receive readable error pages for missing routes and other HTTP failures; API and HTMX error responses retain their machine-readable contracts.
• App mount roots redirect to their trailing-slash URL so relative stylesheets and assets resolve within the app, including Dev Docs.
• App bundles include Bootstrap Icons stylesheets and fonts when referenced by CSS, even without standalone SVG icon references.
• New app builds invalidate browser HTTP caches once per build without clearing login sessions or local user storage. Unversioned assets require revalidation.
• Repeat purchases create fresh cart reservations instead of reusing confirmed reservations from prior orders, preventing provider checkout conflicts.

Architect

• Media extraction uses one platform-helper implementation; Architect artifact preparation and helper transport live in the Architect crate without duplicate OCR or speech engines in the root runtime.
• Editor history renders a bounded list when source-file history reaches the query limit, instead of failing the page.

• Source-edit results update their own panel without replacing the editor workspace; navigation retains its reusable target.
• Fixed visual edits that failed validation after deployment. A newly added form row now saves and remains available when the user reopens the app.
• Fixed element placement so new rows appear inside the editable page. Information cards below the page boundary remain separate from the app.
• Fixed deletion of nested elements, including icons, so the selected item disappears from the saved page.
• Fixed task context and preview behavior so accepted files and later requests stay associated with the same app.
• Imported YAML and JSON projects initialize previews on the configured database backend and become viewable after import instead of remaining in Preparing preview.
• Deleting an edited project removes its version chain without violating restrictive references or deleting another project.

UCAL

• Service editors use their declared icon controls and exclude inactive technicians from assignments and service summaries.
• Service assignment inputs match the save operation; valid short durations and display-order changes persist without being silently overwritten.
• Service editing places Cancel in the card header, groups bounded numeric controls, and aligns color and image controls. Image selection shows the filename and preview; removal shows None and the selected service color.
• Service image uploads persist after Save and appear on managed service cards. Deleted services disappear from the management list; compact cards overlay Edit Service on the image’s upper-right corner.
• Reopening Edit Service preserves the mounted image URL in the client preview. Editor rows use compact, consistent spacing.
• Managed service cards provide a lower-right Delete Service overlay with confirmation. Edit Service places image controls below the preview, technicians beside the image, and Save at the bottom-right.
• Service creation, editing, and deletion return to the business management page. The Services URL redirects to that consolidated workspace.
• Quick Add Service provides a linked color picker and hex field and persists the selected service color.
• Service cards and editor previews without images display their selected color and initials from every word in the service name.
• Service order pickers exclude deleted services; creation offers one new position and editing offers only existing active positions.
• Booking options use aligned, compact input rows with matching Add and Remove icon controls. Service deletion confirmations place the destructive action at the bottom-right.

• Reuse bounded SQLite/Turso database handles instead of reopening the engine for each logical operation, reducing authenticated page latency while preserving independent transactions and file-replacement detection.

• Business creation places Cancel beside the header and uses the shared Create Business icon.

• Managed business cards follow creation order through one shared query implementation, with new businesses appended last across all supported backends.

• Deleting a business returns to Manage Businesses. Business deletion dialogs align controls correctly and suppress unnecessary scrolling.

• Business editing keeps payment controls in independent forms, with valid HTMX targets and multipart uploads. Public/private buttons reflect the current status, and delete dialogs stay within the viewport.

• Business calendars open on today’s date instead of the latest appointment; explicit date and month navigation remains available.

• Restored UCAL business-detail pages for authorized owners.

Menu SPA

• Order numbers include the date so the daily sequence can restart without colliding with orders from earlier days.
• Cart and checkout Back controls work when opened directly and keep their navigation target available.

Dynamic App

• Rejected-action reports retry definite concurrent write conflicts instead of silently losing diagnostics to background worker updates.
• HTMX preview controls load the declared task-list fragment instead of a disabled runtime-state endpoint. Declared-page HTMX requests use their normal renderer when no feature renderer is assigned.

Payments

• Replacing provider credentials requires fresh account verification and invalidates pending OAuth callbacks. UCAL and storefront owners can verify new credentials after an unfinished connection without retaining the previous account’s capabilities.

• Connection-test success feedback confirms Stripe authentication and the configured account, rather than implying that saving credentials verifies a connection. Smoke tests distinguish rejected synthetic credentials from controlled provider success.

Database

• Business counts, tenant roles, management permissions and appointment access use shared domain policies through generic database operations. Credential and session lookup rules are shared across adapters, including expiry and revoked-session handling. Guards prevent these read policies from being reimplemented separately by each backend.

Server runtime

• Default developer checks and the full local app smoke enforce HTMX contract guards for declared routes/actions, target bindings, form structure, and rendered response fragments.

• Static app routes with trailing slashes resolve their declared page artifacts correctly, including mounted directory pages.

• Fixed intermittent bad-request pages during navigation. Unused browser connections close without receiving an error page.

Database

• Fixed backend-dependent ownership, session, and rate-limit handling so supported backends enforce the same security rules.

Developer documentation

• Documentation pages use mounted asset URLs, preserving CSS, icons, and scripts on directory URLs with or without trailing slashes.

• Documentation builds select the shipping runtime feature set instead of enabling every optional engine and host bridge. Cargo/Rustdoc orchestration belongs to the documentation crate and uses locked local dependencies.

Platform validation

• Linux x86_64 GNU passed installed-package validation and the full nine-app QA smoke matrix. macOS x86_64 uses native host smoke checks.
• This release has an explicit operator-approved exception for native macOS ARM64 and Windows x86_64 execution because suitable systems are unavailable. macOS ARM64 receives cross-build and package integrity checks; Windows receives cross-build, package integrity and Wine smoke checks. These checks do not constitute native platform validation. The exception applies only to v0.8.3.

Artifacts published for v0.8.3

• pharos_0.8.3_amd64.deb
• pharos-0.8.3-linux-x86_64-gnu.tar.gz
• pharos-0.8.3-darwin-x86_64.pkg
• pharos-0.8.3-darwin-arm64.pkg
• pharos-0.8.3-windows-x86_64-msvc.zip
• SHA256SUMS-0.8.3.txt

Base apps shipped in v0.8.3

• todo_list, commerce_spa, dynamic_app and static_app.

Apps validated for v0.8.3

• Architect, UCAL, Commerce SPA, Menu SPA, Dynamic App, Todo List, Static App, Developer Docs and LLight passed QA smoke checks. Architect, UCAL, Menu SPA and Developer Docs app archives are published separately.

v0.8.2 — 2026-09-28

New Features

• Architect is a model-driven app builder with a connected in-browser editor. It turns a product brief into generated Pharos source, opens the app for review, and keeps source export and validation tied to the generated project.

- Create an app from a brief and optional context files. - Review generated source and open a validated running preview after the app has materialized. - Edit managed page elements in the browser with right-click editing, group selection, parent traversal, and compact style controls. - Reopen generated apps and imported source apps for later edits. - Inspect source, exports, data-model panels, and page-layout panels from the editor. - Generate dashboard and KPI app layouts with compact field rows, dynamic dropdown values, and date/time controls that fit the form. - Download full source archives that exclude runtime databases, runtime state, vault files, uploads, temp files, secrets, and dist. - Read app metadata from pharos.app.yml and preserve projects when the same output app id is built again. - Configure bounded LLM vendor settings for cloud or local providers while keeping source writes, migrations, validation, and exports under the built-in builder.

• Platform helper binaries move heavy optional work out of the main runtime. Media extraction, barcode/QR decode and encode work, docs generation, and ops orchestration use separate helper paths.
• QR and barcode support includes generation as well as reading. Apps can use the helper path for tickets, reservations, fast links, and scanned-code flows without loading that work during ordinary server startup.

Included changes

• Release packaging keeps server and app versions separate. A runtime package upgrade does not require separately deployed app bundles to move to the same version.
• Debian, macOS, Windows, and Linux tarball packages include the split helper binaries alongside the main pharos runtime.
• Linux releases include both a Debian package and a GNU tarball built from the same release binaries.

Performance and runtime work

• SQL-backed apps no longer use JSON runtime state as request-time authority. Sessions, declared feature actions, generated API mutations, jobs, webhooks, and app records use the relational backend when relational runtime authority is configured.
• JSON runtime state stays in the file-backed/static lane or in explicit import/export and backup/restore flows. A relational app may still declare a runtime.state_path for export compatibility, but normal requests skip JSON-state locks and mutation helpers.
• SQLite migration startup checks use a cache keyed by the migration ledger and migration contract checksums, avoiding false invalidation from normal SQLite DB/WAL/SHM touch behavior.
• SQLite migration drift verification batches migration ledger, journal, and required-table reads through one connection. This removed the repeated database open/query loops slowing down apps and app loading. Server startup speed is significantly faster after migration-cache work.
• /health and /ready report different states. /health can report that the process is alive, while /ready waits for the loaded app set so quarantined apps do not count as full app availability.

Fixes and refinements

• Fixed UCAL startup behavior by removing the route-demanded runtime-state projection path from relational startup and keeping SQL as the active authority.
• Fixed migration drift in commerce_spa, dynamic_app, and ucal.
• Fixed release package assembly so helper binaries do not get treated as app roots and packaging strip steps do not overwrite the selected runtime binary.
• Fixed docs-builder coupling so pharos-docs-builder does not pull SQLite/Turso into its helper graph.
• Fixed media-helper coupling so media entrypoints live outside the general runtime media module and can run as separate work, not server startup work.
• Fixed Architect task deletion for generated apps with editor version history, so deleting a task removes the task card and generated preview state cleanly.
• Fixed Architect queued-task cleanup, context-file upload diagnostics, and export visibility so View and Download export only appear after validation.

Deployment notes

• External LLM vendors are optional. The built-in builder, local validation, source export checks, and runtime contracts remain authoritative for generated apps.
• SQL-backed apps should keep sessions and app records in SQL. Redis remains an optional cache layer in this release.
• Runtime data must live outside app install footprints. Replacing app bundles under dist/apps or a deployed app directory must not delete databases, generated source, vaults, uploads, logs, or state directories.
• Server and app versions are separate. The Debian package can update the runtime and package-owned built-in apps while separately deployed apps keep their own version until they are intentionally redeployed.

Artifacts published for v0.8.2

• pharos_0.8.2_amd64.deb
• pharos-0.8.2-linux-x86_64-gnu.tar.gz
• pharos-0.8.2-darwin-x86_64.pkg
• pharos-0.8.2-darwin-arm64.pkg
• pharos-0.8.2-windows-x86_64-msvc.zip
• SHA256SUMS-0.8.2.txt

Base apps shipped in v0.8.2

• todo_list
• commerce_spa
• dynamic_app
• static_app

Apps validated for v0.8.2

• architect
• todo_list
• static_app
• dynamic_app
• commerce_spa
• ucal
• dev_docs
• menu_spa
• llight

v0.8.1 — 2026-09-12

New Features

• Generic payment-provider management is available as a reusable runtime capability, with provider-neutral account status, encrypted credential storage, checkout-mode control, provider audit events, callback nonce validation, and app-declared route/action wiring.
• Stripe is the first concrete payment provider, supporting credential validation, Stripe-hosted Checkout Sessions, success and cancel return handling, signed webhook confirmation, failure/expiration/refund/dispute event handling, and fulfillment only after verified provider confirmation.
• Beacon Beats can run either demo checkout or live Stripe-backed checkout per store, with owner-managed credentials, payment-flow debugging cards, Stripe-hosted customer purchase flow, and download unlocks tied to confirmed payment events.
• UCAL can run either demo appointment booking or Stripe-backed prepaid appointment booking per business, with owner-managed credentials, customer payment return handling, webhook-confirmed appointment payment status, and calendar visibility for recorded appointments.

Included changes

• Beacon Beats owner, cart, checkout, library, order-detail, and payment-provider screens were refined so the payment flow is usable end to end while preserving demo mode as the default fallback.
• UCAL business settings now host payment-provider and Google Calendar controls in the edit-business flow, keeping business configuration in one app-owned declarative surface.
• UCAL booking and calendar screens were refined for paid and unpaid appointment creation, technician assignment, appointment detail dialogs, selected-day rendering, and dynamic availability filtering.
• Payment-provider copy and provider wiring moved into app-owned data/payment_provider.yml files so future providers can be added without spreading provider metadata through the main app manifests.
• Local and live smoke expectations were updated to match reusable payment-provider copy and current Beacon Beats and UCAL flows.
• macOS release packaging is split into separate x86_64 and arm64 installer artifacts so each architecture is built, verified, checksummed, and published independently.

Fixes and refinements

• fixed payment-provider credential persistence so app rebuilds and restarts do not erase saved owner credentials or checkout mode.
• fixed Beacon Beats cart, checkout, and library state transitions so confirmed purchases clear cart state and unlock downloads only after payment confirmation.
• fixed UCAL appointment redirects so successful bookings return to the app appointments view instead of placeholder or duplicated route paths.
• fixed UCAL calendar rendering so selected days, days with bookings, and appointment detail dialogs present consistently.
• fixed internal booking controls so date, service, start time, and technician changes dynamically filter unavailable combinations before submission.
• fixed macOS release-build isolation so x86_64 and arm64 build lanes use separate target directories, binary outputs, package names, and cross-build images instead of sharing a universal build lane.

Notes

• Production payment collection requires runtime-owned payment-provider secrets and app-owner credentials. PHAROS_PAYMENT_PROVIDER_STATE_KEY, PHAROS_PAYMENT_PROVIDER_SECRET_KEY, and the Stripe webhook signing secret must be configured outside the tracked app bundle.
• Stripe test-mode validation is documented in docs/program/payment_provider_test-plan.md; a live low-dollar transaction and refund should be completed before broad production use.

Artifacts published for v0.8.1

• pharos_0.8.1_amd64.deb
• pharos-0.8.1-darwin-x86_64.pkg
• pharos-0.8.1-darwin-arm64.pkg
• pharos-0.8.1-windows-x86_64-msvc.zip
• SHA256SUMS-0.8.1.txt

Base apps shipped in v0.8.1

• todo_list
• commerce_spa
• dynamic_app
• static_app

v0.8.0 — 2026-09-04

New Features

• MySQL is now a primary Pharos database backend, with runtime configuration, queries, mutations, migrations, and deployment proof coverage
• MongoDB is now a primary Pharos database backend, with runtime configuration, queries, mutations, migrations, and deployment proof coverage
• Redis is now available as an optional runtime cache layer, including secure configuration validation, worker-local connection lifecycle, session caching, and cache-backed acceleration paths that degrade safely on cache miss or cache unavailability
• In-app payment-provider management is now available behind app-declared policy gates, with Stripe Connect as the first provider and a provider-neutral account, callback nonce, audit, state-transition, and redaction model

Included changes

• dev_docs moved further toward manifest-owned branding and documentation selection, including the new Pharos Framework wordmark asset path in apps/dev_docs/pharos.app.yml
• dev_docs docs inclusion was cleaned up so the nav, generated outputs, and shipped pages stay aligned without route-by-route source hardcoding
• UCAL business admins can connect, refresh, and disconnect payment providers from the app-owned business settings surface instead of relying on app-specific Stripe booleans or placeholder routes
• Beacon Beats checkout and owner-reporting copy now derives from apps/commerce_spa/pharos.app.yml payment-mode declarations so the demo storefront can later switch to provider-backed checkout without template rewrites
• Beacon Beats storefront presentation was tightened across hero, trust-strip, catalog, filter, and card spacing so the tutorial app reads consistently and fits documentation screenshots better
• Beacon Beats marketing copy and tutorial surfaces were refined so the quickstart flow describes the app in clearer product language instead of placeholder-style filler
• quickstart documentation for the audio-store tutorial now uses refreshed Beacon Beats screenshots that match the current app presentation
• release-preparation guidance was tightened around version ownership, public asset naming, and the current public release subset

Fixes and refinements

• fixed dev_docs 404 exposure caused by stale navigation and docs-selection drift
• fixed docs-app branding drift so wordmark changes can be made from declarative app manifest fields instead of framework source edits
• fixed remaining stale release references in user-facing and maintainer-facing docs that still pointed at older 0.7.x assets
• fixed Beacon Beats asset cache-buster drift by aligning shipped CSS and JS query versions with the release contract

Notes

• dev_docs remains a separately published app archive rather than a packaged app inside the base Pharos install.
• ucal remains a separately published app archive rather than a packaged app inside the base Pharos install.
• docs/bill_of_materials.md is generated release evidence and must be regenerated from the final 0.8.0 build outputs before publication; it was not hand-edited as part of this source-prep pass.

v0.7.24 — 2026-09-02

Included changes

• production-readiness closure work archived with proof ledgers, validation paths, and narrower claim surfaces
• demo-app documentation deepening completed across todo_list, commerce_spa, ucal, and dev_docs
• stronger app-centered tutorial flow in the docs app, including the cleaned Tutorial Order page and refined tutorial-order reference page
• typed hook and middleware widening across the native runtime, generated surfaces, and proof paths
• transaction and action-contract widening for derived inputs, default inputs, normalization, annotations, and broader declarative mutation coverage
• SQLite build-boundary split and version-source cleanup so expensive build inputs are cached more predictably and release versioning stays synchronized
• commerce_spa usability refinements across cart, checkout, simulated purchase flow, totals display, related teaching copy, and invalid-login handling
• local proof paths tightened so the built dev_docs app is reviewed through a real shared-runtime temp tree before release closure
• program-plan cleanup and archive movement for materially completed work

Fixes and refinements

• fixed docs link rewriting so direct doc links and release-install references resolve correctly in generated dev_docs
• fixed dev_docs backlink generation and added regression coverage for that route family
• fixed shared-runtime session cookie precedence so app behavior follows the intended runtime-owned cookie rules
• fixed the backup and restore validation lane to read database.migration_contract correctly while preserving compatibility fallback for older manifests
• fixed release-version drift by synchronizing the repository version contract around VERSION and the root workspace package version
• fixed PHAROS_CONFIG drift by removing redundant wrapper-driven environment mutation and keeping the config path set in one real place
• fixed Zig tool and cache path drift so cross-build inputs use the unified location expected by the current build flow
• fixed llight iframe hosting and product-panel cleanup issues that were interfering with the hosted app presentation
• fixed commerce_spa UI and flow issues including empty-cart behavior, purchase simulation flow, checkout totals, pricing display, and owner-facing purchase surfaces
• fixed UCAL login rendering so invalid-login and login-page responses render the shared form fields instead of failing with a runtime error
• fixed dynamic_app home rendering by escaping literal template braces that were being parsed as empty tokens in the shared renderer
• fixed packaged runtime deploy ordering so bundled SQLite app migrations run only after the shared runtime is stopped, avoiding live database lock failures during package rollout
• fixed docs-app navigation, tutorial ordering, and rendered teaching surfaces so the shipped examples read as one coherent ladder instead of scattered references

Notes

• dev_docs remains a separately published app archive rather than a packaged app inside the base Pharos install.
• ucal remains a separately published app archive rather than a packaged app inside the base Pharos install.
• follow-on expansion work stays in active feature plans and is not part of the scoped 0.7.24 release claim.

v0.7.23 — 2026-08-28

Pharos v0.7.23 shipped the native Pharos runtime, the pharos CLI, and a set of packaged example apps that show the framework path from a minimal SPA to a larger dynamic application.

Included changes

• shared native runtime for hosted Pharos apps
• CLI for build, verify, serve, migrate, and packaging flows
• packaged example apps that can be installed directly and run without cloning the repository
• YAML-first app authoring compiled into runtime-ready JSON artifacts
• shared multi-app hosting under app-local base paths
• SQLite and PostgreSQL relational backend support
• packaged runtime health, readiness, version reporting, logging, and app-local config overrides