Aksara [v0.7.2] — Audit Closure

[nagarjuna-tella]

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 remain green.

There is also no change to the stable synchronous MCP contract.

Ordinary Tasks remain a separate, lighter execution abstraction.

PostgreSQL remains the foundation

Aksara remains PostgreSQL-first.

v0.7.2 adds no additional database backend and no Redis, Kafka, Celery, or Temporal requirement.

Production-shaped validation continues to include restricted:

• NOSUPERUSER
• NOBYPASSRLS

roles with forced RLS and multi-tenant isolation.

Validation

The v0.7.2 release candidate passed the complete supported compatibility matrix:

• Python 3.11 / minimum web boundary — 8,545 passed
• Python 3.11 / latest web boundary — 8,545 passed
• Python 3.14 / minimum web boundary — 8,545 passed
• Python 3.14 / latest web boundary — 8,545 passed

Additional candidate validation included:

• 232 focused audit-closure tests
• 213 installed-wheel closure tests
• 54 Task tests
• 5 real-process Task scenarios / 10 ownership invariants
• 234 Durable Operations tests
• 24 production-bound invariant tests
• 68 MCP tests
• 22 restricted-role/RLS tests
• 430 security tests
• 165 fuzz tests
• 314 diagnostics tests
• 458 migration tests
• 127 documentation-contract tests
• 348 Python documentation fences
• 15 JSON examples
• 295 CLI forms
• six-stage Ticket Desk with 86 assertions
• 15 installed-package checks
• 66 packaged Support Desk checks
• all 4 scaffold templates
• strict TypeScript SDK compilation and live-client verification
• 12/12 Doctor checks
• strict MkDocs build of 162 pages
• 42,339 internal links/assets validated
• 41 selected external links validated
• 7/7 performance sanity invariants
• Ruff and mypy ratchets
• Bandit
• dependency audit
• Gitleaks
• package/Twine validation
• CycloneDX SBOM validation
• complete hosted CI matrix

Compatibility

v0.7.2 intentionally tightens behavior where v0.7.1 was incorrect.

Examples include:

• unauthorized custom actions now deny access;
• unsafe storage paths are rejected;
• ambiguous model names now raise instead of silently selecting a model;
• stale Task workers can no longer mutate authoritative state;
• malformed configuration fails predictably.

These are correctness fixes, not new product features.

Normal non-colliding v0.7.1 applications remain source-compatible.

What v0.7.2 does not do

This release does not introduce:

• a unified application Capability abstraction;
• a new Action runtime;
• a new agent runtime;
• multi-agent orchestration;
• persistent AI memory;
• workflow DAGs;
• additional database engines;
• new infrastructure dependencies;
• a new provider ecosystem;
• v0.8 roadmap functionality.

Those belong to future architectural work.

---

v0.7.1 asked:

What does Aksara actually do?

v0.7.2 answers:

Now make every defect that audit exposed correct.

With this release, the finite v0.7 audit/correctness cycle is complete.

Public truth established the debt. Audit closure eliminates it. The next phase returns to abstraction.

---

This discussion was created from the release Aksara [v0.7.2] — Audit Closure.