Phlo 1.1: what a fleet of real apps asked for, and a promise from here on

Phlo 1.1 is the release that ran under a fleet of real apps before it got its number. Wherever those apps worked around the engine, with a check of their own, a copy of a resource or a try/catch around a call that should not throw, the engine now does the work. Most of an upgrade is deleting those workarounds.

Security comes as resources you switch on, never as defaults: a CSRF guard that covers the whole app before any route runs, accounts on your own user model with single-use tokens and a second factor, signed webhooks, and a policy per CSP directive with allow. Data holds up under load: a model's scope holds for writes as well as reads, a save writes only the columns it changed, objUpsert() and objIncrement() work in the database itself, migrations run each file in a transaction with a lock and a hash, and a cache moves on when the write commits. Privacy got the same care: a visitor without consent is a pseudonym of the day in visitors, the daemon logs a token as the start of its hash, and lastmod dates a page by the commit that changed it instead of the day it was deployed.

New resources cover what apps kept building: mail, markdown, sanitize_html(), qr, feed, files/ICS, lang.address with locale, mcp to offer the app to agents, offline for pages and posts without a line, and binary for one executable that needs nothing installed. build::lint names a resource an app uses and did not enable, and reflect::audit lists what an app still has to change.

Closing those gaps broke things a minor release should not, once. Every break is marked in the changelog, and the migration guide says what an app changes, in the order it meets them: build, lint and audit until all three are clean. An app moves on its own; the others keep running on the engine they have.

From 1.1 on, the versioning promise holds strictly: a patch fixes, a minor adds, and a break waits for 2.0, announced by a deprecation in a minor first.

Engine 1.1. See the guide.