Aksara [v0.7.2] — Audit Closure

Aksara v0.7.1 was built around one rule:

Public documentation should describe what the installed framework actually does.

Running that audit against real packages, PostgreSQL, generated applications, public examples, and client code exposed 22 concrete functional defects.

v0.7.2 closes that entire ledger.

22 findings were reproduced.
22 were fixed.
0 remain unresolved.

This is deliberately not a feature release.

It establishes a clean correctness baseline before Aksara returns to its next architectural phase.

Authorization consistency

Custom ViewSet actions now honor their declared authorization boundary.

ViewSet permissions apply unless an action explicitly overrides them, authentication and request checks run before the handler, and detail actions preserve object and tenant checks.

The previous case where generated CRUD could deny an anonymous caller while a supposedly protected custom action executed is closed.

Existing generated REST, MCP, and Durable Operations policy paths remain intact.

Filesystem storage containment

FileSystemStorage now uses component-aware resolved-path containment rather than string-prefix comparison.

Save, read, existence checks, delete, size, path, and related local operations reject:

• parent traversal;
• sibling-prefix escapes;
• absolute escapes;
• symlinks resolving outside the configured root.

Symlinks that remain inside the storage root continue to work.

FileField retains its independent validation.

Tenant and query-scope preservation

Soft-delete visibility transformations now preserve the original QuerySet state.

Filters, Q expressions, tenant predicates, ordering, limits, annotations, eager-loading state, and database/session context survive with_deleted() and only_deleted().

Restricted-role forced-RLS testing confirms that both the application predicate and database policy remain effective.

Multitenant example correction

The historical multitenant example no longer treats / as a universal startswith() exemption.

Protected routes now execute tenant resolution instead of accidentally bypassing it.

The canonical Ticket Desk and Support Desk applications remain the preferred isolation references.

Model identity and migration correctness

Aksara's canonical internal model identity is now the module-qualified class name.

Simple model names remain convenient when unique.

If multiple registered models share the same simple name, Aksara now raises AmbiguousModelError instead of silently selecting one based on import order.

This closes the defect where an application User model could be replaced by the built-in User, allowing migration generation to succeed while silently omitting the application's declared table.

Model discovery, migrations, relations, fixtures, Admin, and model inspection now propagate ambiguity instead of hiding it.

Relation loading

select_related(...).first() now honors requested eager-loading semantics consistently with all().

Coverage includes:

• nullable and non-null foreign keys;
• one-to-one relationships;
• multiple eager fields;
• ordering;
• missing results;
• query-count sanity.

Typed bulk updates

bulk_update() now generates field-aware PostgreSQL casts for searched CASE values.

The previously failing Boolean and timestamp cases now work, along with representative coverage for:

• text;
• integer;
• float;
• decimal;
• UUID;
• date;
• time;
• datetime;
• duration;
• Enum;
• nullable values;
• supported advanced PostgreSQL fields.

Existing transaction and batching semantics are preserved.

Fixture round-tripping

Fixture behavior has been repaired across three separate findings.

JSON fixture loading can now restore exported rows with explicit primary keys into an empty table while retaining the documented existing-row conflict behavior.

YAML exports now use safe, portable scalar representations for UUID and temporal values and remain compatible with safe_load.

Default database dumps correctly enumerate canonical model classes instead of registry-name strings.

Round-trip coverage includes UUID identity, foreign keys, Boolean, timestamps, nulls, JSON, and arrays.

Fixtures remain development/data-movement utilities rather than disaster-recovery guarantees.

Pagination

Generated HTTP responses now preserve the metadata produced by the selected paginator.

This includes:

• page;
• size;
• total pages;
• limit/offset;
• cursor state;
• next_cursor.

Paginator-specific metadata is represented correctly in OpenAPI as well.

Cursor clients can now obtain and use continuation tokens through the real HTTP surface.

Ordinary Task ownership

Ordinary background Tasks now have explicit current ownership.

Claims use:

• worker identity;
• random claim token;
• database-time lease;
• renewable heartbeat;
• atomic stale recovery;
• conditional terminal updates.

When ownership transfers, the previous claim becomes invalid.

A stale worker cannot:

• renew the new owner's lease;
• overwrite the new owner's success;
• overwrite the new owner's failure;
• move authoritative task state backward.

Real multi-process tests cover healthy long-running tasks, paused workers, hard worker death, competing workers, stale completion, and stale failure.

Ordinary Tasks are still at-least-once.

They remain distinct from Durable Operations and still require repeat-safe handling of irreversible external effects.

An additive internal migration introduces the new Task claim-ownership fields.

TypeScript SDK

The generated TypeScript SDK now compiles under TypeScript 5.9.3 strict mode without suppressing errors or widening the generated surface to any.

Coverage includes:

• models;
• optional and nullable fields;
• create/update payloads;
• list parameters;
• filters;
• search;
• ordering;
• pagination;
• custom actions.

A live generated client successfully exercises the candidate application's list, detail, create, update, query, and cursor-pagination paths.

Generated application packaging

Generated Basic, Blog, CRM, and multitenant projects now include intentional Hatchling package selection rather than depending on package-name inference.

Clean generated applications pass:

• documented editable installation;
• wheel build;
• isolated wheel installation;
• imports.

The basic clean-room journey additionally passes migrations, tests, server startup, health checks, REST create/list, shutdown, and restart from the installed application wheel.

Testing utilities

test_database(cleanup=True) now pins supported same-task database/model work to the transaction it owns.

Rollback behavior is verified for:

• successful exit;
• exceptions;
• cancellation;
• nested transactions;
• direct execute/query;
• model saves;
• independent observer visibility;
• repeated use;
• pool cleanup.

HTTP requests and separate processes remain outside that same-task transaction boundary and are explicitly documented as such.

Configuration parsing

List-valued environment settings now use a portable grammar.

JSON arrays are canonical, with unambiguous comma-separated input available for convenience.

URI schemes, ports, IPv4, bracketed IPv6, whitespace, empty input, explicit Python lists, malformed input, POSIX, and Windows behavior are covered.

os.pathsep is no longer used as a generic URI-list separator.

Python compatibility diagnostics

The environment compatibility checker now agrees with package metadata and the supported release matrix:

• Python 3.9: unsupported
• Python 3.10: unsupported
• Python 3.11–3.14: supported
• later versions: unsupported until validated

The previous false pass for Python 3.10 is removed.

Experimental provider and workflow correctness

Several deterministic bugs in Experimental AI surfaces were fixed without changing their stability classification.

Provider detection now distinguishes:

• adapter defaults;
• explicit configuration;
• reachability;
• authentication;
• health.

A clean environment no longer reports a default local Ollama endpoint as explicitly configured.

Keyless custom HTTP endpoints are recognized according to the adapter's real contract.

Direct aksara.ai.workflows imports now succeed in clean processes regardless of import order.

Diagnostic workflow rendering no longer produces malformed duplicated assignments such as:

export DATABASE_URL=export DATABASE_URL=...

These fixes do not promote AI/provider/workflow quality to Stable.

Inspector provenance

Query-plan results now explicitly identify provenance as:

• live;
• synthetic;
• failed;
• unavailable.

They also report whether ANALYZE actually executed.

Offline synthetic output can no longer masquerade as measured EXPLAIN ANALYZE data.

Inspector remains Experimental.

Admin rendering

ArrayAdminWidget.render() no longer mutates the caller-provided list when adding display rows.

Rendering now operates on a copy while preserving existing escaping and server-side validation behavior.

Admin's broader stability classification is unchanged.

Upgrade compatibility

A realistic application created with public v0.7.1 was upgraded to the v0.7.2 candidate.

The upgrade preserves:

• organization/application data;
• users and relations;
• existing queued ordinary Tasks;
• existing succeeded Durable Operations;
• authorized REST behavior;
• MCP availability;
• Admin;
• migration replay.

The new internal Task ownership migration applies successfully and idempotently.

Durable Operations and MCP

There is no semantic change to Durable Authorized Operations.

The full Durable Operations regression and invariant campaigns ...

Aksara [v0.7.1] — Documentation & Developer Experience

Aksara v0.7.1 focuses on a different kind of framework correctness:

public truth.

After the Durable Authorized Operations work in v0.7.0, the framework had reached the point where its capabilities were growing faster than its public explanation.

v0.7.1 rebuilds the developer experience around one principle:

What the documentation says should match what the installed framework actually does.

This release introduces no intentional runtime capability or semantic change. Instead, it audits, rewrites, executes, and verifies the public surface around the existing v0.7 backend.

A clearer first experience

The documentation now has a deliberate reader path:

• Home — understand what Aksara is and whether it fits
• Start — build the first real application
• Build — learn application concepts and framework capabilities
• Operate — production, migrations, diagnostics, workers, and durability
• MCP — stable synchronous MCP integration
• Reference — exact configuration and API behavior
• Experimental — AI, Studio, and evolving functionality kept separate from the stable backend contract

The previous collection of competing starter applications and entry points has been consolidated around one canonical learning path.

One progressive Ticket Desk tutorial

The primary tutorial now grows one application instead of repeatedly starting over.

It covers:

1. first project and protected CRUD
2. relationships and validation
3. tenant isolation
4. ordinary background tasks
5. Durable Operations
6. optional synchronous MCP

The final candidate executed the six-stage tutorial with 86 public API assertions against an installed Aksara wheel and PostgreSQL.

Quick Start and onboarding

The first-project experience has been rewritten around the actual scaffold, CLI, configuration, migrations, and generated REST behavior.

A new user can follow one documented route from:

install
→ create project
→ configure PostgreSQL
→ migrate
→ run
→ authenticate
→ use the API

without needing source-code archaeology or internal architecture documents.

Durable Operations as a user-facing capability

v0.7.0 introduced Durable Authorized Operations.

v0.7.1 substantially improves how they are explained.

The documentation now clearly distinguishes:

• Operation — one logical durable request
• Attempt — one physical execution
• idempotency
• leases
• fences
• worker replacement
• current reauthorization
• durable approval
• cancellation
• PostgreSQL atomic execution
• external-effect ambiguity
• ordinary tasks versus Durable Operations

The user documentation no longer assumes familiarity with ADR 0001 or distributed-systems terminology.

Stable, Evolving, and Experimental boundaries

Capabilities are now much more explicit about maturity.

Stable backend surfaces are separated from evolving and experimental functionality.

In particular, the documentation no longer presents experimental AI, planner, workflow, search, or Studio functionality as if it had the same contract as:

• ORM
• migrations
• REST
• identity
• permissions
• tenancy
• tasks
• synchronous MCP
• Durable Operations

AI remains an optional consumer of the application backend rather than the foundation of the getting-started experience.

Configuration and production guidance

The configuration reference and production manual were substantially revised.

They now distinguish:

• explicit settings and environment precedence
• migration role versus application role
• restricted PostgreSQL roles
• RLS requirements
• ordinary workers versus durable workers
• Doctor and deployment checks
• retention
• outbox/export responsibilities
• backup and monitoring responsibilities
• upgrade procedures

The production documentation also makes clearer what Aksara guarantees and what remains the application's or operator's responsibility.

Examples and scaffolding

Repository examples were audited and given explicit roles rather than being treated as equally authoritative starter applications.

The scaffold documentation and CLI instructional text were improved without changing generated runtime behavior.

The final candidate verifies that, after release/version normalization, generated application behavior remains equivalent to v0.7.0 aside from instructional README guidance.

Executable documentation

A major goal of v0.7.1 was to make public documentation testable.

The final release candidate validates:

• 348 current Python documentation snippets
• 15 JSON examples
• 295 documented CLI forms
• 5 retained repository examples
• the six-stage Ticket Desk tutorial
• generated scaffold startup
• installed-wheel behavior
• packaged Support Desk behavior
• rendered documentation links and assets

Public examples are increasingly treated as product surface rather than unverified prose.

Public-truth audit

The v0.7.1 audit corrected 80 documentation contradictions.

These included stale or incorrect claims around areas such as:

• authentication
• permissions
• ViewSets
• serializers
• relations
• queries
• migrations
• Admin
• tasks
• tenancy
• middleware
• storage
• debugging
• AI
• Studio
• MCP
• Durable Operations
• CLI
• testing
• deployment

The rule throughout the release was:

Documentation follows implementation truth.

No runtime feature was added simply to make an old example correct.

Functional findings discovered

The audit also surfaced 22 functional findings.

Those findings remain deliberately unfixed in v0.7.1 because this release preserves a strict no-functional-change boundary.

Examples include issues affecting areas such as:

• ordinary task stale-lock recovery
• TypeScript SDK strict compilation
• scaffold editable installation
• relation-loading consistency
• pagination metadata
• fixtures
• model discovery/migrations
• testing helpers
• storage path handling
• configuration parsing
• experimental workflow imports

These are now documented and available for separately reviewed maintenance work.

v0.7.1 does not hide those limitations or quietly change production behavior.

No runtime semantic change

The release scope guard confirms:

• runtime logic changed: No
• dependencies changed: No
• schema/migrations changed: No
• disclosed functional findings fixed: 0 of 22

Production/package differences from v0.7.0 are limited to:

• version metadata
• documentation
• existing CLI help/instructional text
• scaffold README guidance
• template descriptions

Validation

The final v0.7.1 candidate passed:

• 8,389 passed, 2 expected skips in every supported Python/web-stack matrix cell
• 258 Durable Operations tests
• 24 production-bound invariant tests
• 68 MCP tests
• 40 task compatibility tests
• 21 RLS/tenancy tests
• 429 security tests
• 165 fuzz tests
• 314 diagnostics tests
• 455 migration tests
• 123 documentation-contract tests
• 15/15 installed-wheel checks
• 66/66 packaged Support Desk checks
• 12 Doctor checks with no warnings or failures
• 7/7 performance sanity invariants
• 21/21 hosted checks, including PostgreSQL 16

Strict MkDocs builds 162 pages.

42,322 internal links/assets and 41 selected external links were validated.

Ruff and mypy ratchets, Bandit, dependency audit, Gitleaks, Twine, and package validation also passed.

Compatibility

v0.7.1 preserves the runtime contract of v0.7.0.

Existing applications retain the same behavior for:

• ORM
• migrations
• REST
• identity
• permissions
• tenancy
• background tasks
• Durable Operations
• MCP
• CLI
• diagnostics

No new service or runtime dependency is required.

Release artifacts

aksara_framework-0.7.1-py3-none-any.whl

SHA-256:

42a3a42be08ee5be1075d4f6da3b22fea6acaa5bf678a57db7ecc00ce4fdd197

aksara_framework-0.7.1.tar.gz

SHA-256:

d3ce8e4b8c735bfcf61b41f2df90c7cc7a448722e8329b7f074bb9840653cb94

---

v0.7.0 made Aksara's authorized operations durable.

v0.7.1 makes the framework itself substantially easier to understand and evaluate:

The public documentation now aims to be an executable description of the framework that actually ships.

Aksara [v0.7.0] — Durable Authorized Operations

Aksara v0.7 makes authorized backend operations durable.

v0.6 established the rule that AI agents and tools must execute inside the same authentication, tenancy, permission, policy, transaction, and audit boundaries as the rest of the application.

v0.7 extends that model across time and failure.

An operation can now outlive the HTTP request, process, or worker that started it while preserving authoritative state, scoped retry identity, current authorization, fenceable ownership, approval and cancellation intent, and recoverable execution history.

Durable Operations

Aksara now provides a first-class durable execution model built around two concepts:

• Operation — the authoritative logical request.
• Attempt — one physical execution of that Operation by a worker.

Operations are stored in PostgreSQL and survive:

• request loss
• application restart
• worker crashes
• worker replacement
• retry delays
• approval waits
• cancellation
• transient execution failures

The current PostgreSQL Operation row remains authoritative. Attempts and transition records explain execution history without becoming a separate source of truth.

Safe retries and scoped idempotency

Durable submissions can use scoped idempotency.

The identity includes the relevant application, tenant, initiating principal, action/version, client key, and normalized semantic input.

This means:

• concurrent identical submissions resolve to one logical Operation
• retrying after a lost response returns the same Operation
• reusing the same identity with changed input fails deterministically
• deduplication remains explicitly time-bounded rather than being promised forever

A lost response is therefore no longer a reason to blindly repeat a mutation.

Clients can reread authoritative Operation state or safely resubmit the same idempotency identity.

Database-time leases and fencing

Each physical claim creates a new Attempt with:

• worker ownership
• lease expiry
• monotonically increasing fence

Lease decisions use PostgreSQL time rather than worker clocks.

If Worker A owns fence N, its lease expires, and Worker B later acquires fence N+1, Worker A can no longer:

• heartbeat
• update authoritative execution state
• retry
• cancel
• finalize
• perform a guarded application mutation

The ownership check happens before application SQL inside the protected transaction.

This prevents a stale worker from waking up after replacement and corrupting application state.

Atomic PostgreSQL execution

For supported postgres_atomic actions, Aksara provides a strong same-database guarantee.

The following share one guarded PostgreSQL transaction:

• ownership validation
• application mutation
• Attempt success
• Operation success
• result persistence
• transition evidence
• outbox intent

They commit together or roll back together.

This means Aksara does not produce durable state where a supported application mutation committed but the Operation still claims it did not succeed, or vice versa.

The guarantee applies only to supported writes through the owning Aksara Database and guarded execution context.

Independent database connections, separate databases, subprocess/thread mutations, direct connection-pool escapes, and external network effects are outside that atomic boundary.

Authorization across time

Durable execution does not freeze authorization at admission time.

Aksara stores non-secret principal provenance, not reusable credentials or permanent authority.

Before supported delayed effects, the framework resolves the current Principal and checks current:

• identity
• tenant membership
• scopes
• action authorization
• PolicyEngine decisions

Application-specific object, permission, field, and model validation continue to belong to the registered action authorization boundary.

If a user loses permission while an Operation is waiting, the old admission decision does not grant permanent access.

Durable approvals

Approval decisions can now survive worker and process loss.

A durable decision is bound to the exact:

• Operation
• action/version
• normalized input
• tenant
• requester
• approver
• expiry

Approval records intent.

It does not replace authorization.

If the requester loses permission after approval, execution still fails current authorization.

Durable cancellation

Cancellation is now durable intent.

It can prevent future work when it wins the race against execution, including while an Operation is waiting, ready, delayed, or running.

Cancellation does not:

• undo already committed PostgreSQL work
• reverse an external effect already sent
• rewrite a successfully completed Operation

Completion and cancellation compete through the authoritative Operation row.

Background task integration

Existing Aksara background tasks remain supported.

Tasks can optionally schedule durable Operations, but task state does not become execution authority.

For linked work:

• the task schedules execution
• the Operation owns logical state
• the Attempt owns physical execution
• the fence controls current ownership

Existing unlinked v0.6 task APIs, IDs, queues, scheduling, and CLI behavior remain compatible.

External effects

Aksara explicitly distinguishes external-effect behavior.

Supported effect classes include semantics for:

• idempotent providers
• reconcilable at-least-once providers
• nonretryable providers
• read-only work

Before an external mutation, Aksara can persist durable intent and a stable operation-scoped effect identity.

On recovery:

• idempotent providers reuse the same downstream key
• reconcilable providers are checked before repeating work
• unreconcilable ambiguity becomes external_outcome_unknown

Aksara does not claim exactly-once execution for arbitrary external systems.

PostgreSQL and an external provider do not share one atomic transaction.

Operational history and outbox

Durable Operations include bounded transition evidence and transactional outbox intent.

This supports:

• diagnostics
• export
• operational history
• external audit pipelines

The current Operation row remains authoritative.

Aksara does not turn this into event sourcing or claim that application-owned history is a tamper-resistant compliance ledger.

Retention

Durable state is intentionally bounded.

The framework supports retention and pruning for:

• terminal Operations
• Attempts
• results
• errors
• transitions
• approval decisions
• idempotency identities
• outbox records

Active work is protected, and idempotency identities remain available for their promised deduplication window.

Compatibility

Durable Operations are additive and opt-in.

Existing applications do not need to:

• register durable actions
• mount the durable router
• start durable workers
• use task-backed Operations

Existing v0.6 behavior remains in force for:

• ORM
• migrations
• generated REST
• synchronous MCP
• identity
• permissions
• tenancy
• background tasks
• CLI
• diagnostics
• signed synchronous approval grants

Principal remains Aksara's runtime authority type.

MCP

Existing synchronous Streamable HTTP MCP remains supported.

Protocol-level durable MCP Tasks are not included in v0.7.

The current official MCP Python SDK does not yet implement the io.modelcontextprotocol/tasks extension, and Aksara does not introduce a competing private wire protocol.

Durable Operations are therefore available independently of protocol-level MCP Tasks.

Infrastructure

PostgreSQL remains the only mandatory durable authority.

v0.7 does not add mandatory dependencies on:

• Redis
• Kafka
• Celery
• Temporal
• another coordination database

What remains experimental or deferred

v0.7 does not stabilize:

• planner quality
• persistent AI conversations or sessions
• memory
• multi-agent execution
• autonomous workflows
• provider-specific quality
• Studio AI internals
• generic workflow/DAG composition
• approval workflow UX
• long-term compliance retention
• protocol-level MCP Tasks

DurableStep also remains an evolving workflow-step cache and does not inherit the new Operation/Attempt guarantees.

Validation

The final v0.7.0 release passed:

• 8,271 full-suite tests with 2 expected skips
• 8,271 passed, 2 skipped in each supported Python 3.11/3.14 runtime matrix cell
• 258 durable-operation tests
• 24 production-bound invariant tests
• 429 security tests
• 165 fuzz tests
• 314 diagnostic tests
• 455 migration tests
• 114 documentation-contract tests
• 15/15 installed-wheel checks
• 66/66 packaged Support Desk checks
• 7/7 performance sanity invariants
• 21/21 hosted release checks with PostgreSQL 16

Doctor completed with no warnings, failures, or blockers.

Ruff and mypy ratchets passed.

Bandit, dependency audit, Gitleaks, Twine, strict documentation, package validation, and CycloneDX SBOM validation also passed.

Upgrade notes

After installing v0.7.0:

1. Run aksara migrate using the migration role.
2. Grant the restricted application role the required DML and sequence privileges on the new internal tables.
3. Register all durable action and principal resolver versions before starting workers.
4. Run check_durable_operations() for each deployed application/tenant profile.
5. Start explicitly tenant-scoped durable workers and the application-owned outbox exporter where used.
6. Configure and monitor Operation, result, error, idempotency, and audit-retention windows.
7. Keep old action/resolver versions deployed while nonterminal Operations still reference them.

Release artifacts

`aksara_framewo...

Aksara [v0.6.1] — Installed-Package Truth

Aksara v0.6.1 is a post-v0.6 adoption and trust release.

v0.6.0 established Aksara's Production Mode foundation and stable AI/MCP execution boundary. v0.6.1 focuses on making sure the product developers install is the same product our documentation, scaffolding, package metadata, and examples describe.

This release does not introduce a new architectural subsystem.

Instead, it removes ambiguity, fixes several developer-experience inconsistencies, strengthens clean-install validation, and makes the stable/experimental boundary much clearer.

Highlights

One configuration story

Generated Aksara projects now use the framework's global settings authority rather than creating a separate settings instance that could disagree with runtime configuration.

CLI database commands now follow the documented precedence:

AKSARA_DATABASE_URL
        ↓
DATABASE_URL

DATABASE_URL remains supported as a compatibility alias.

Configuration guidance has also been simplified so new projects have one obvious recommended path while compatibility settings remain available.

Stable-core-first scaffolding

Newly generated projects now start from the stable Aksara core.

Experimental surfaces such as provider-backed AI, MCP exposure, and Studio are explicitly enabled when needed rather than being silently assumed by the scaffold.

This makes a fresh project easier to understand and keeps experimental capabilities from looking like required infrastructure.

Clear MCP endpoints

The documentation now consistently distinguishes the two MCP-related surfaces:

/mcp/

The actual MCP Streamable HTTP protocol endpoint used by MCP clients.

/ai/tools/mcp

The inspection/catalog surface for generated tool metadata.

Public examples, settings documentation, security guidance, and getting-started material now use the correct endpoint for each purpose.

Canonical authenticated MCP journey

The primary developer path now demonstrates the actual stable execution model:

Model
  ↓
Migration
  ↓
Generated REST API
  ↓
Server-resolved Principal
  ↓
Generated MCP tool
  ↓
Official MCP client at /mcp/
  ↓
Authorized invocation
  ↓
Persisted PostgreSQL result

The example includes the server-side identity step required for authenticated MCP execution rather than implying that an MCP client chooses its own authority or tenant.

Better authentication failure behavior

Requests running without Starlette authentication middleware are now treated as anonymous instead of failing before Aksara's normal authorization path can run.

This preserves the framework's permission model and produces the expected authorization behavior rather than an unrelated request-context exception.

AI documentation now matches the package

Several public AI pages previously presented conceptual or historical APIs such as AgentRuntime and Planner as if they were current importable interfaces.

v0.6.1 removes that ambiguity.

Executable examples now use APIs that actually exist in the installed package.

Planner behavior, provider abstractions, investigation/session state, autonomous execution, memory, and Studio AI remain clearly marked as experimental or evolving rather than part of the stable v0.6 contract.

Accurate background-task contract

Background-task documentation previously implied complete Principal restoration across queued execution.

The current durable task record persists tenant context, not the full Principal authorization provenance required for delayed reauthorization.

The documentation and regression coverage now reflect that actual contract.

Full durable Principal provenance and reauthorization remain part of the planned v0.7 architecture rather than being partially introduced in this patch.

Package and release truth

Project metadata, version references, and public descriptions have been refreshed to match the current framework.

The repository now also includes final v0.6.0 release evidence in addition to the historical RC evidence, improving future release archaeology.

Documentation that executes

v0.6.1 adds stronger semantic documentation checks.

High-value public examples are now validated against the APIs we actually ship instead of relying primarily on literal documentation locks.

The public example audit covered 1,704 code/documentation blocks with no broken or stale executable classifications.

Installed-wheel release gate

A new installed-package gate validates the main developer journey from a built wheel rather than an editable source checkout.

The validated flow includes:

wheel install
→ CLI
→ project scaffold
→ model
→ migrations
→ PostgreSQL
→ Doctor
→ OpenAPI / REST
→ MCP catalog
→ official MCP client at /mcp/
→ authorized task_create invocation
→ persisted row visible through REST
→ clean shutdown
→ database pool released

This helps ensure repository-only imports or local development assumptions cannot make a broken public package appear healthy.

Validation

The v0.6.1 candidate passed the complete supported runtime matrix:

• Python 3.11
• Python 3.14
• minimum supported FastAPI/Starlette boundary
• latest supported FastAPI/Starlette boundary

Each full matrix run completed with:

8,010 passed, 2 expected provider-dependent skips

Additional release validation included:

• 461 migration tests
• 429 security tests
• 162 fuzz tests with 3 expected skips
• 314 diagnostics tests
• 81 MCP/security-boundary tests
• strict MkDocs build
• installed-wheel PostgreSQL integration
• official MCP client integration
• Doctor release policy with zero warnings, failures, or blocks
• Ruff/mypy non-increasing debt ratchet
• Bandit
• dependency vulnerability audit
• Gitleaks
• CodeQL
• CycloneDX SBOM
• wheel/sdist build
• Twine validation
• isolated package import
• all hosted GitHub release checks

Stable v0.6 contract remains unchanged

v0.6.1 preserves the stable Production Mode foundation introduced in v0.6.0:

• async PostgreSQL ORM
• migrations
• generated REST APIs
• authentication and Principal model
• permissions and PolicyEngine
• documented tenant isolation contract
• MCP Streamable HTTP
• generated executable MCP tools
• execution-time authorization
• tenant and field enforcement
• bounded approval grants
• deterministic execution audit events
• structured errors
• transaction rollback
• cancellation
• runtime limits
• CLI and Doctor release diagnostics

No stable v0.6 API was intentionally removed.

Still experimental

The following remain intentionally outside the stable production contract:

• planner behavior
• investigation/session state
• persistent AI conversations
• agent memory
• multi-agent workflows
• durable autonomous workflows
• provider-specific model quality
• provider-selection abstractions
• automatic code/patch execution
• Studio AI internals

These capabilities may continue evolving without expanding the v0.6 compatibility promise.

What's next

v0.6.1 intentionally does not begin the next architectural milestone.

The direction toward v0.7 is:

Durable authorized operations

If v0.6 made Aksara agent execution safe, v0.7 aims to make authorized work identifiable, queryable, recoverable, reauthorized, idempotent within the framework-owned database boundary, cancellable, and auditable across workers and application restarts.

Before implementation, that architecture will be defined through an explicit operation/state-machine design rather than grown incrementally from the existing experimental Agent APIs.

Upgrade

Install or upgrade with:

pip install -U aksara-framework==0.6.1

For production deployments, continue to:

• run migrations separately before application startup
• use a restricted PostgreSQL application role
• enable/force RLS where required by the tenancy contract
• run:

aksara doctor production-check --release

before release/deployment.

---

Aksara v0.6.1 is fundamentally a trust release:

the package, the scaffold, the docs, and the runtime now tell the same story.

Aksara [v0.6.0] — Production Mode

Aksara v0.6.0 is the first release we consider suitable for real production backends within a clearly defined and tested stable surface.

This release is the result of a broad correctness and production-readiness effort across the ORM, migrations, API layer, tenancy, security, runtime lifecycle, packaging, diagnostics, and AI/MCP execution boundary.

The goal of v0.6 is not to declare every Aksara feature stable.

It is to establish a backend foundation — and an AI execution boundary — that can be relied upon.

Highlights

Production-ready backend foundation

v0.6 hardens the core framework behavior across:

• async PostgreSQL ORM
• transactions and session lifecycle
• migrations
• generated REST APIs
• serializers and field validation
• authentication and principals
• permissions and PolicyEngine
• multi-tenancy and PostgreSQL RLS
• Admin
• CLI
• diagnostics and Doctor
• background task lifecycle
• packaging and release validation

Database acquisition and transaction startup are now exception-safe and cancellation-safe, including cleanup after partial startup failures.

The release also introduces explicit runtime compatibility boundaries across the supported Python, FastAPI, and Starlette versions.

Advanced ORM field contracts

Array, Vector, JSON, FileField, and ImageField behavior has been hardened across ORM, migration, serialization, API, and Admin boundaries.

The framework now has explicit behavior for cases including:

• nested and invalid arrays
• nullable values
• JSON scalar values
• SQL NULL versus JSON null
• non-finite numeric input
• Vector dimensionality and precision
• File/Image path representation
• server-controlled and forbidden fields

Unsupported behavior fails explicitly rather than being partially or accidentally supported.

Official MCP protocol support

Aksara now integrates the official Model Context Protocol Python SDK.

v0.6 exposes MCP over Streamable HTTP at:

/mcp/

Application models and actions can be exposed as executable MCP tools with generated JSON Schemas.

Supported tool behavior includes:

• discovery
• create
• retrieve
• list/filter
• update
• delete
• custom actions

where permitted by application policy.

One authorization boundary for REST and MCP

MCP is not a separate authorization system.

Tool execution flows through the same application contract used by generated APIs.

At invocation time Aksara enforces:

• authentication
• principal identity
• credential scope
• credential audience and expiry
• tenant
• roles and permissions
• PolicyEngine rules
• object access
• field-write restrictions
• validation
• transaction behavior
• approval requirements

Authorization is checked at execution time rather than being trusted from tool discovery or model planning.

AI agents as first-class principals

Aksara's AI-native architecture treats agents as application principals rather than anonymous functions calling backend APIs.

Invocation context can carry:

• agent identity
• initiating principal
• tenant
• scope
• policy context
• request ID
• run ID
• tool-call ID
• approval context

This context is isolated across concurrent executions and propagated through authorization, tool execution, and audit records.

Approval-gated actions

v0.6 introduces signed, scoped, expiring approval grants for operations that require human authorization.

Approval can be bound to the exact:

• principal
• tenant
• tool
• arguments
• approver
• decision
• expiry

Changed, rejected, expired, invalid, or mismatched approvals cannot authorize a mutation.

Authorization is checked again when the approved action executes.

This is an execution-safety boundary, not a durable human-workflow engine.

Deterministic AI/MCP audit events

MCP execution now produces structured audit events describing the decision and execution context.

Audit events support correlation across:

• principal
• agent
• tenant
• request
• run
• tool call
• policy decision
• approval
• result

Sensitive argument values and approval tokens are excluded from the default audit record.

Applications can route these events to structured logs, JSONL, or application-owned sinks.

Runtime safety controls

Agent and provider execution can now be bounded independently of model prompts.

Supported runtime limits include:

• maximum tool calls
• planning-step limits
• per-tool timeout
• provider timeout
• overall execution timeout
• cancellation
• replay rejection
• provider-reported token limits
• provider-reported cost limits

A model cannot simply ignore these limits through prompting.

Structured errors and transactional rollback

MCP/tool failures use stable error categories:

• client
• authorization
• transient
• internal

Failed operations roll back database transactions, including failures after partial mutation.

Production validation

v0.6 was validated across the complete supported runtime matrix.

The final release-candidate validation included:

• 7,995 tests passed
• Python 3.11 and 3.14
• minimum and latest supported FastAPI/Starlette boundaries
• PostgreSQL-backed test execution
• PostgreSQL 16 hosted validation
• PostgreSQL 18.4 local validation
• pgvector
• real MCP client integration
• packaged-wheel production reference application
• generated REST/MCP contract equivalence
• restricted-role tenant isolation
• approval and authorization abuse cases
• concurrency and principal-context isolation
• transaction rollback
• cancellation and shutdown cleanup
• migration bootstrap and upgrade
• security and fuzz suites
• Doctor release policy
• Bandit
• dependency audit
• Gitleaks
• CodeQL
• CycloneDX SBOM generation
• strict documentation build
• wheel and sdist validation
• isolated package installation
• static-analysis debt ratchet

The packaged Support Desk reference application validated the framework from the installed distribution rather than only from the source checkout.

Stable v0.6 surface

The v0.6 stable contract includes the core backend and deterministic AI execution boundary:

• ORM core
• migrations
• generated APIs
• authentication
• principals
• permissions
• PolicyEngine
• documented tenant isolation contract
• Admin
• CLI
• Doctor/release diagnostics
• MCP Streamable HTTP
• generated MCP tools
• execution-time MCP authorization
• AgentPrincipal propagation
• field-write enforcement
• deterministic error handling
• audit events
• runtime limits
• signed bounded approval grants

Experimental surfaces

The following remain intentionally experimental and do not carry the same compatibility or production guarantee:

• autonomous planner behavior
• investigation quality
• persistent AI conversations
• process-local investigation/session state
• agent memory
• multi-agent workflows
• durable autonomous workflows
• automatic code generation and patch execution
• provider-specific behavioral quality
• Studio AI internals

Experimental does not mean unusable.

It means Aksara does not yet promise the same stability and durability guarantees for those surfaces as it does for the v0.6 stable contract.

Known limitations

Approval durability

Approval grants are signed exact-operation grants rather than a durable approval workflow.

Applications requiring single-use approvals, durable review queues, or organization-specific approval history should persist that state themselves.

Replay and process state

Replay protection and related invocation state are currently process-local.

v0.6 does not promise restart-safe or cross-worker global idempotency.

Audit retention

Aksara emits deterministic structured audit events, but durable retention, external storage, retention policy, and access control remain application responsibilities.

MCP transport

Streamable HTTP at /mcp/ is the supported MCP transport for v0.6.

The framework does not expose a stdio transport.

Provider guarantees

Token and monetary budgets depend on accounting information supplied by the model provider.

No claim is made that individual cloud-provider model behavior is certified by this release.

Intentionally deferred

The following were deliberately kept outside v0.6 rather than delaying the stable release:

• custom ManyToMany through models
• object-valued lazy forward foreign keys
• general-purpose cache/Redis parity
• AI memory
• durable investigation sessions
• durable autonomous approval workflows
• multi-agent orchestration
• broad provider certification
• comparative benchmark superiority work
• Studio redesign
• new ORM field families
• repository-wide Ruff/mypy cleanup

Upgrading

Install or upgrade with:

pip install -U aksara-framework==0.6.0

Run migrations as a separate deployment step before application startup.

Production deployments should use a PostgreSQL application role that is:

• NOSUPERUSER
• NOBYPASSRLS

and should enable/force RLS where tenant isolation relies on PostgreSQL policies.

Before deployment, run:

aksara doctor production-check --release

Why v0.6 matters

Aksara started from the idea that AI should not be bolted onto a backend as an unrestricted integration.

v0.6 establishes the foundation for a different model:

AI agents are application principals.

They can discover and invoke application capabilities through MCP, while authentication, tenancy, permissions, field restrictions, policy enforcement, approval boundaries, auditing, and execution limits remain deterministic framework concerns.

The model can decide what it wants to do.

Aksara decides what it is allowed to do.

---

Thank you to everyone who tested, reviewed, challenged, and...

[v0.5.54] — ORM Write & Relation Correctness

v0.5.54 addresses the cross-path inconsistency identified in the ORM correctness audit: bulk_create, QuerySet.update, and relation configuration producing different behavior than equivalent save() calls for the same data.

The rule this release enforces: if save() does it, every write path should do it. Same validation, same field preparation, same auto-field behavior. No surprises depending on which write path you used.

---

Foundation hardening sequence

Version	Area
v0.5.50	Migration safety
v0.5.51	ORM primitive field correctness
v0.5.52	Admin correctness & permissions
v0.5.53	ORM query semantics & migration generation
v0.5.54	ORM write-path & relation correctness

---

Validation

• Full test suite: passing
• Write-path regression suite: passing
• Relation test suite: passing
• Migration operation suite: passing
• Security suite: passing
• Diagnostics suite: passing
• MkDocs strict build: passing
• pip-audit: passing, no known vulnerabilities

---

Install

pip install aksara-framework==0.5.54

---

What's Next

The remaining ORM correctness work:

• Array item typing and nested array policy
• Vector precision policy
• FileField / ImageField .to_python() contract
• JSON scalar behavior
• Lazy forward FK object loading, if added
• Custom through model support, if added
• Additional relation manager features

---

Aksara is pre-1.0 and does not claim production readiness.

[v0.5.53] — ORM Query Semantics & Migration Generation Correctness

v0.5.53 fixes two correctness areas that share the same root problem: code that appeared to work but produced subtly wrong output.

NULL filtering that returned no rows instead of null rows. FK filters that rejected valid column aliases. Migration generation that emitted tables in the wrong order. These aren't crashes — they're the kind of wrong behavior that causes you to doubt your data before you doubt the framework.

This release fixes them.

---

Foundation hardening sequence

Version	Area
v0.5.50	Migration safety
v0.5.51	ORM primitive field correctness
v0.5.52	Admin correctness & permissions
v0.5.53	ORM query semantics & migration generation

---

Validation

• Full suite: 7709 passed, 3 skipped
• Migrations suite: 514 passed
• Security suite: 729 passed, 1 skipped
• Tasks suite: 23 passed
• MkDocs strict build: passing
• pip-audit: passing, no known vulnerabilities

---

Install

pip install aksara-framework==0.5.53

---

What's Next

The remaining ORM correctness work:

• Write-path consistency — bulk_create, upsert, QuerySet.update() aligned with save() semantics
• QuerySet.update() and updated_at
• Vector bulk_update() casting
• Relation DDL safety
• Array, vector, file, and image advanced field policy

---

Aksara is pre-1.0 and does not claim production readiness.

[v0.5.52] — Admin Correctness & Permissions

v0.5.52 hardens the built-in admin interface.

The pattern is the same as the last two releases: find the places where behavior was inconsistent, undocumented, or silently wrong — and fix them. v0.5.50 did this for migrations. v0.5.51 did it for primitive field validation. v0.5.52 does it for the admin layer.

This is not an admin features release. The list view, permissions, bulk actions, CSRF handling, and M2M saves all existed before. This release makes them work correctly.

---

What Changed

Admin mounting is now consistent

The admin docs and implementation previously had multiple mounting patterns that produced different behavior. This release settles on one supported path:

from aksara.contrib.admin import include_admin
include_admin(app)

Custom prefixes work:

include_admin(app, prefix="/manage")

Multi-site routing and namespacing are now more predictable when you have multiple admin sites registered.

---

CSRF cookies now follow the mounted prefix

If your admin is mounted at /manage, the CSRF cookie path is now /manage. Previously it was hardcoded to /admin regardless of where the admin was actually mounted. Forms on custom-prefixed admin sites would break CSRF validation silently.

---

Permission enforcement is now consistent

Admin permission handling had gaps across different views. They're closed:

• Site permission classes are now honored during login, not just after
• Model and module permissions are applied on the admin index and app index pages — previously these checks were inconsistently applied
• Object-level permissions are checked before bulk actions run
• Custom permission hooks can now be safely async
• Session lookup failures are logged instead of silently swallowed

The practical effect: what a user is allowed to do in the admin is now the same regardless of which view they're accessing.

---

Bulk actions check object-level permissions

Previously, a user with model-level access could execute bulk actions on any selected objects, even ones they shouldn't be able to modify individually.

Now bulk actions run object-level permission checks before acting on each selected object. Objects the user cannot access are skipped or denied explicitly — not silently included.

---

M2M saves are transactional

Many-to-many save handling had two problems:

1. Invalid related IDs were silently ignored — the relation would save partially without telling you
2. The relation was cleared before new IDs were validated, so an invalid selection could leave the relation empty

Both are fixed. Related IDs are validated before any mutation. The update is transactional — if any ID is invalid, the relation is not touched.

---

Readonly fields are enforced on create and update

A crafted POST could previously set readonly fields by including them explicitly in fields or fieldsets. They were readonly in the UI but not enforced server-side.

Readonly fields are now rejected on both create and update paths.

---

Boolean checkboxes render correctly

A saved False value was being converted to the non-empty string "False" before the template rendered it. Non-empty strings are truthy in Python, so the checkbox rendered as checked even though the stored value was False.

Fixed. Saved False renders as unchecked.

---

Admin list view is usable on real tables

The list view has been expanded with what you'd expect from a real admin:

• Search
• Pagination
• List filters with bounded choice loading — no more loading every option for a column with 10,000 distinct values
• Actions
• Configurable clickable columns
• Ordering
• Safer "show all" behavior

---

AksaraFilterBackend is now the preferred name

DjangoFilterBackend was a placeholder name from early development. The preferred name is now AksaraFilterBackend.

DjangoFilterBackend remains available as a compatibility alias — existing imports won't break:

from aksara.api.filters import AksaraFilterBackend  # preferred
from aksara.api.filters import DjangoFilterBackend   # still works
assert DjangoFilterBackend is AksaraFilterBackend    # same object

---

Compatibility

These changes may affect existing admin customizations:

If you have...	What to check
Custom admin prefix	CSRF cookie path has changed — verify forms work
Custom permission classes	Now applied during login, not just after
Bulk actions	Now check object-level permissions — some objects may be skipped
M2M fields in admin forms	Invalid IDs now surface as errors instead of being ignored
Readonly fields	Now enforced server-side — crafted POSTs can no longer bypass them
DjangoFilterBackend imports	Still works, no action needed

For most users: include_admin(app) and everything works as documented.

---

Documentation

The admin docs have been significantly refreshed to match the actual implementation. Previous docs referenced app.mount("/admin", admin) which was never a supported pattern. Updated areas:

• Admin setup and site configuration
• Custom prefixes and multi-site routing
• CSRF behavior and warnings
• Admin vs Studio — when to use each
• Permissions and async permission patterns
• Object-level bulk action safety
• Readonly field behavior
• Actions, filters, widgets, pagination
• Branding and template customization

---

Validation

• Full suite: passing
• Admin test suite: passing
• Security test suite: passing
• Diagnostics test suite: passing
• MkDocs strict build: passing
• pip-audit: passing, no known vulnerabilities

---

Install

pip install aksara-framework==0.5.52

---

What's Next

The foundation-hardening work continues. After migrations (v0.5.50), primitive fields (v0.5.51), and admin (v0.5.52), the remaining ORM correctness items are next:

• filter(field=None) → IS NULL semantics
• FK alias filtering and reverse FK filter consistency
• bulk_create / write-path consistency with save()
• Relation DDL safety

---

Aksara is pre-1.0. This release improves admin correctness and permissions but does not constitute an external audit or production-readiness claim.

[v0.5.51] — ORM Primitive Correctness

v0.5.51 continues the ORM correctness work started in v0.5.50.

v0.5.50 made migrations safer. v0.5.51 makes the values that flow through the ORM more predictable. Specifically: what you pass into a field is now what gets validated and stored — no silent coercions, no hidden truncations, no Python truthiness surprises.

This is not a complete ORM correctness release. Query semantics, write-path consistency, relation safety, and advanced field behavior are on the roadmap. v0.5.51 is scoped to primitive field validation only.

---

What Changed

Integer fields now reject non-integral values

Previously, passing 1.9 to an integer field would silently store 1. Passing True would store 1. Passing "10.5" would store 10.

None of those are integers. They're silent truncations that hide a caller mistake rather than surfacing it.

Integer, SmallInteger, BigInteger, and their Positive variants now reject:

• Non-integral floats (1.9, 2.5)
• Non-integral Decimals (Decimal("1.2"))
• Decimal strings ("10.5")
• Booleans

Integral values still work: 1, 1.0, Decimal("1.0"), "10". PostgreSQL boundary validation runs before persistence.

---

Boolean fields now use explicit parsing, not Python truthiness

The previous behavior: Boolean().to_db("False") returned True. A non-empty string is truthy in Python, so the value went straight through.

The new behavior: Boolean fields use an explicit accept-list.

Accepted as True: true, 1, yes, y, on Accepted as False: false, 0, no, n, off

Anything else — including "maybe", "False", "0.0" — raises ValidationError. The field now means what it says.

---

Decimal fields enforce precision and scale before persistence

Previously, Decimal(max_digits=5, decimal_places=2).to_db("1.234") would pass the value to PostgreSQL, which would round it silently to 1.23. The ORM accepted it, the database changed it, and nothing told you.

Now the ORM enforces max_digits and decimal_places before the value reaches PostgreSQL. Out-of-range values raise ValidationError with the field configuration in the message.

Financial data should not be rounded silently by the database.

---

Float fields reject NaN and infinity

NaN, Infinity, and -Infinity are now rejected at the field level.

These values have unusual equality semantics (NaN != NaN), unusual storage behavior, and no business in a normal ORM round-trip. They were previously accepted silently.

---

Email validation rejects invalid local-part dot placement

The following patterns now raise ValidationError:

• a..b@example.com — consecutive dots
• .abc@example.com — leading dot
• abc.@example.com — trailing dot

Valid addresses like first.last@example.co continue to pass.

---

Community files added

Added Code of Conduct, contribution guide, issue templates, and a pull request template. If you've been thinking about contributing, the path is clearer now.

---

Compatibility

These changes are intentional correctness fixes. Values that were previously accepted through silent coercion may now raise ValidationError.

If you're upgrading from v0.5.50, check these specifically:

Was accepted	Now raises
Integer().to_db(1.9)	ValidationError — not an integer
Boolean().to_db("False")	ValidationError — use False or "false"
Decimal(max_digits=5, decimal_places=2).to_db("1.234")	ValidationError — exceeds decimal_places
Float().to_db(float("nan"))	ValidationError — NaN not accepted
Email().to_db(".abc@example.com")	ValidationError — invalid local-part

---

Validation

• Full suite: 7619 passed, 3 skipped
• Field target suite: 266 passed
• Security suite: 424 passed, 1 skipped
• Diagnostics suite: 305 passed
• MkDocs strict build: passed
• pip-audit: passed, no known vulnerabilities

---

Install

pip install aksara-framework==0.5.51

---

What's Next

The ORM correctness roadmap continues:

• filter(field=None) must emit IS NULL, not = NULL
• FK alias filtering and reverse FK filter consistency
• bulk_create / write-path consistency with save()
• Relation DDL safety
• Array, vector, file, and image field policy

Each item will get its own focused release.

---

Aksara is pre-1.0 and does not claim production readiness.

[v0.5.50] — Migration Safety & Correctness

Migrations are the one place where a framework bug doesn't just cause an error — it corrupts your data or leaves your schema in an unknown state. v0.5.50 is entirely focused on making that surface safe.

This is not a features release. It's a correctness release. If you're building on Aksara, this is the one you want in production before v0.6.0.

---

What Changed

Transactional execution
Python migrations now run inside a single transaction. The migration record is written inside the same transaction as the migration operations — so a failed migration doesn't leave a tracking row behind claiming it succeeded. SQL files are split and executed statement-by-statement inside a transaction.

Advisory locking
PostgreSQL advisory locking now prevents concurrent migration runners from applying the same migrations simultaneously. If you're running migrations in CI and a developer runs them locally at the same time, they won't step on each other.

Checksum verification
Aksara now records a checksum when a migration is applied and verifies it before running pending migrations. If you edit an already-applied migration file, the mismatch is caught before anything runs. Line endings are normalised before hashing so you don't get false mismatches across platforms. Legacy rows without stored checksums are still compatible — they warn instead of blocking.

Circular dependency detection
The migration graph now detects circular dependencies explicitly instead of silently producing an invalid execution order.

Safer SQL parsing
The SQL migration parser now handles multiple statements per line, semicolons inside strings, quoted identifiers, dollar-quoted blocks, and CRLF line endings correctly. Unterminated strings, blocks, and comments fail fast instead of producing invalid SQL silently.

SQL generation guardrails
Generated constraint names are quoted, length-bounded, and hash-suffixed when they would exceed PostgreSQL's identifier limits. Partial-index predicates, ArrayField types, NUMERIC/DECIMAL/VARCHAR precision forms are all validated more accurately.

Cleaner failure output
Failed migration runs now report which pending migrations were skipped. CLI errors for expected graph and load failures surface cleanly instead of leaking raw tracebacks. Advisory-lock contention guidance now correctly explains how to identify a stuck backend.

---

What This Doesn't Include

Deliberately deferred for a later design pass:

• Migration metadata schema versioning
• Checksum backfill for legacy rows
• app_label / name identity split
• Dedicated migration verification command

These are documented as deferred, not forgotten.

---

Validation

• Full DB-backed suite passing
• Migration suite passing
• Security suite passing
• Diagnostics suite passing
• MkDocs strict build passing
• pip-audit clean — no known vulnerabilities
• Release Gate passing on main

---

Install

pip install aksara-framework==0.5.50

Upgrading from an earlier version? Run in a development or CI database first:

aksara migrate --dry-run
aksara migrate

If you have existing migration history, review any checksum warnings carefully. Legacy rows without stored checksums are allowed — but if a stored checksum doesn't match, that means a migration file was edited after it was applied. That's worth knowing before you run anything.

---

No production-readiness claim is introduced by this release. Aksara remains pre-1.0.