ddcore 0.1

This series was written after the fact, from the repository's history. It records what an app would notice in each release — a capability, a contract, a default — and not every commit that went into it.

0.1.2 — 2026-09-11

Fixed

• An account is administered, and a refusal says so. User granted All an ifOwner read, and the owner of a User row is whoever created the account, so the grant freed no row at all while still passing every doc-less check: the DocType travelled in the boot payload, the desk listed it, and the list came back 200 with the query quietly narrowed to nothing, where a refusal belonged. User is now System Manager only; what a person may do to their own account keeps going through the profile service.
• The server writes its log to stdout, where a platform reads it as output instead of painting every line — INFO included — as an error. Every other command keeps the log on stderr, because there stdout belongs to the command: an exported NDJSON, a printed API key, doctor --json or the MCP JSON-RPC stream.

0.1.1 — 2026-09-11

Changed

• The example app left this repository for ddcore-demo, where it is built against the published binary and takes the path a real app takes. What stays here is apps/testapp, the fixture internal/acceptance needs.

Fixed

• The language picker's own labels and the profile's field rows are translated like everything else.

0.1.0 — 2026-09-11

The first release.

Added

• The framework: file-based DocType metadata with controllers and lifecycle hooks, role permissions, REST and RPC endpoints, a generated Desk with forms, lists, reports and workspaces, jobs and a scheduler, files, Version and Comment, the ddcore CLI, an MCP server, and typings generated from the metadata.
• Internationalization: English is the canonical language and every user-facing string is a catalogue key, translated on the server for metadata and mirrored into the runtime for app code. ddcore i18n extract builds the catalogue and a missing key fails the build; the language resolution chain, one timezone per site and regional formatting come with it, and the Go core, the CLI, the MCP server and the developer errors all speak keys. See i18n.
• Money and dates (DAT-06): an exact decimal rounding kernel shared by the server, the app runtime and the Desk, the site's currency precision and rounding rule applied to coercion and to what a Currency field commits, and one site clock. An impossible precision is refused at migrate.
• Export (DAT-02): a whole DocType with its children and an attachment manifest, over GET /api/export/<DocType> and ddcore export, permission-checked on the server, capped, and flagged as truncated only when something was actually cut. The list's export offers the whole filtered set rather than the page on screen. See export.
• Migrations (DAT-04): declared renames through renamedFrom, a refused conversion where data could be lost, and phased patches in patches/NNNN_name.ts. Compound business keys through uniqueKeys (DAT-05), checked before the write and enforced by a partial unique index under concurrency. See migrations.
• extendDoctype (DAT-09): one app adds fields and property overrides to another app's DocType, versioned like the rest of the metadata. See extensions.
• Single DocTypes through isSingle (DAT-03): one configuration document per DocType, with defaults before the first save, permissions on the read and on that save, and Desk editing at /app/{doctype}.
• Authentication and account self-service (SEC-04): password recovery and invitations over public routes with single-use tokens, a password minimum every path goes through, a lockout that answers 429 instead of taking another guess, one source for the session TTL and a cookie that says Secure, a profile with sessions and API keys of one's own behind an avatar menu, and ddcore user invite|unlock|sessions from the terminal. A minimal SMTP transport with a pluggable send method carries the messages. See authentication.
• Configuration split (SEC-04): the environment in .env, the site's decisions in ddcore.json, with an integration secret living in the environment rather than in a column (SEC-06).
• Operations (PRD-03): liveness separated from database readiness, a request correlation id and a duration on every request, queue failure and age signals, thresholds in ops, and a doctor that reports instead of dying when the database is down. See operations.
• Distribution (PRD-02): a release workflow that publishes static archives for Darwin and Linux on amd64 and arm64 with SHA256SUMS, an install.sh, ddcore version with the version injected at build time, and PORT/DATABASE_URL support for a platform deployment.