Development

Shipped

Development, at /admin/development in your Turbobase app (administrators only), is where changes to your instance are proposed, designed, shipped, and watched. It is one pipeline behind a shared tab strip — Proposals · Solutions · Releases · App Management · Processes — so an idea moves from raw input to a monitored deploy without leaving the surface. Opening the bare /admin/development URL lands you on Proposals, the pipeline’s first stage.

Proposals

Every piece of development work starts as a proposal. The Proposals list shows each one (newest first) with its evidence count and lifecycle status — draft → complete → realized → documented — plus labels and epics for grouping, and live badges: Working when the AI is actively processing a proposal in the background, Active once work has started on a draft. Archiving a proposal is a reversible hide, not a lifecycle change — unarchive it any time from the Archived view.

Raw inputs feed the pipeline through the Inputs drawer, opened from an icon with a count badge in the Proposals header. It collects everything worth reacting to — free-text notes you drop in, uploaded documents, data query results, and signals the platform raises on its own — for triage: dismiss what’s noise, archive what can wait, and select what matters. Pressing Start composes the selected inputs into a fresh draft proposal and opens it in Studio; anything you typed in the request box becomes your first chat message there. The same composer and Inputs drawer also lead your instance’s home dashboard, so you can start a proposal the moment you open the app — it stays disabled until the initial sync finishes.

Create a proposal by email

You don’t have to be in the app to start a proposal. Forward or CC an email to your instance’s proposal address — or grab your personal create-address from the email icon in the Proposals header — and the message, with its attachments, opens a fresh proposal. Reply to a proposal’s own proposal+<token>@… address and the reply is attached to that proposal as evidence, redrafting it if it’s still open; once a proposal is marked complete it’s frozen, so a later reply is recorded against it but changes nothing.

Each address carries a token that authorizes it, so there’s no open catch-all inbox — mail to an unrecognised address is dropped, not turned into a proposal. Every inbound message is triaged to one of three outcomes: attached to an existing proposal, used to create a new one, or ignored.

Studio

Studio is the chat-first authoring canvas for one draft proposal — a conversation with the AI, with everything it is working from on the left and everything it is producing on the right:

Left — Inputs. The signals, evidence (in fact and interpretation lanes), notes, documents, and data attached to this draft. Each lane can add and remove inputs.
Center — the conversation. You shape the proposal by talking to the AI; its replies stream in as it works, and the composer sits at the bottom. Earlier revisions live behind a History control in the header.
Right — living artifacts. The proposal draft, re-rendered as the AI writes it, alongside a portfolio overview and the solutions it plans to mint.

Mark complete is the freeze point: it moves the proposal to complete and mints its planned solutions into the Solutions stage. After that its evidence and body are locked — further edits go through an explicit change request, so what was approved stays what was approved.

Solutions

A completed proposal mints solutions — the concrete deliverables that realize it. Kinds include hooks, source changes, conduits, configuration, documentation, apps, data manipulation (a bounded, previewed, idempotent data fix applied as a one-shot job, never a deploy), and native (work your instance already covers out of the box). A documentation solution is authored about its sibling change — the doc explains the very change shipping alongside it. The Solutions tab is the standalone pipeline stage listing every solution across all proposals, each with its origin proposal, target record type, current status, source system (where it lands on one), and the release that ships it.

Releases

Every deploy through Turbobase is a tracked release: gated, audited, monitored, reversible. The Releases tab lists each release with the solution it delivers, its target source, and its lifecycle status (pending, deploying, live, rolled back, failed, or superseded by a newer release). Each row also carries git provenance — the repository, commit, and pull request the deployed artifact was built from. Turbobase holds no repository credential and clones nothing; provenance is links only.

Every release gets a per-release monitor: a pre-release health baseline compared against live samples taken after the deploy, with per-object error accounting. The verdict is deliberately fail-closed — a release only shows healthy when the watch has explicitly verified it against a captured baseline; a missing or unreadable baseline shows as unknown, never healthy. A detected regression files a signal back into Inputs, and rollback is available from the monitor page.

Templates

The Templates icon in the Proposals header opens a gallery of starting points. Picking one creates a proposal seeded from the template and drops you straight into Studio, where you refine the brief conversationally before anything is generated. Templates come in three categories:

Apps — e.g. order management, expense management, a customer grid. The proposal’s brief drives generation of a hosted app served inside your instance at /a/<slug>; see Building apps.
Documentation — e.g. documenting a process as an SOP.
Source changes — e.g. adding a validation rule in a connected source.

Standards

The Standards icon in the Proposals header opens your house-standards library: free-text notes and uploaded documents that record how your business wants things built — requirements, SOPs, policy. A standard you add lands as an unpublished page under the House standards node in the knowledge base; publishing it is what puts it into effect. From then on it grounds proposal drafting, so the AI’s drafts and generated deliverables take it into account automatically.

Apps

The Apps tab manages the hosted apps your instance serves: enable or disable an app, share it with specific users or roles, or delete it. New apps are best started from an app template (above); the tab also offers a blank “Create app” for CLI-first workflows, where you ship builds with turbobase apps deploy.

Which apps can be changed from a user’s request

Every app Turbobase serves carries a floating Suggest a change button, so whoever is using it can describe what they want and file it as a proposal without finding you first. Working one of those automatically means editing the app’s own source, so each row on this tab states whether this instance holds that source:

rev N on the instance — the source is here, with the date it arrived and whether it was pushed by a person or generated by the proposal engine. A change request against this app can be applied automatically.
Not on the instance — the app was uploaded already built. A built bundle cannot be turned back into a project, so a change request against it is still filed and still worth having, but somebody has to make the change by hand. The row names the one command that fixes it for good: turbobase apps push <slug>, run once from the project directory by whoever has it. After that the app behaves like any other.

Somebody who files a request against an app in the second state is told so in the widget as soon as they send it — so nobody is left waiting on something that was never going to happen on its own. Against an app in the first the widget says nothing beyond confirming the request, because nothing on the instance applies a change on its own yet. Their request is filed either way, and it may still be answered as a configuration, script or documentation change rather than an app change.

A turbobase apps deploy run from a source directory records that source itself, so an app shipped that way is never in the second state. See Building apps.

Automations that react to a change request

A request somebody files from an app’s Suggest a change button is a record on your instance, so an automation can react to it. A conduit — the platform’s cross-system bridge — can now watch for one: it fires when a request is filed, again when the planner works out what kind of change it is, and again on every status change, and the run is told which of the three it is so you can react to one moment rather than all of them. Each run sees the request’s title, its text, which app it was filed against, who filed it and its current status, and nothing of the working state behind it.

The same bridge runs the other way. A request arriving somewhere else — a message in a chat channel your instance is connected to, for instance — can be turned into a change request automatically; it lands as a draft for somebody to read, exactly as a person’s filing does, and carries a note of where it came from. An automation can only ever create a draft: approving, shipping or editing a request stays a person’s decision.

More broadly, a conduit can now react to any record saved on your instance, whoever saved it — your app, a background process, the AI assistant, Studio, or another automation — not just to records arriving from a connected system. Each run is told whether the save created or changed the record and which fields moved, so an automation can fire on one transition instead of on every edit.

Processes

/admin/development/processes is the background work your apps have deployed: what exists, how each one is triggered — on a schedule, or only when somebody asks — whether it is switched on, and how its last runs went. It is the one place where somebody who did not deploy a process can find out that it exists at all, which is why it sits at the tail of the same strip. Switch a process off here and it stays deployed and stops running.

Scheduled tasks

/admin/development/scheduled-tasks lists the recurring and one-shot tasks created by asking Pilot, your AI assistant, to schedule something (its schedule-task tool). Each task shows its schedule, status, next and last run, and its recent run history; you can pause, resume, or delete a task from the page. The list covers tasks you own plus tasks shared with you — the platform’s own internal jobs never appear here.

This page is no longer a tab on the Development strip: go to the address directly, or ask Pilot to open it.

Analyzer — where customization risk and usage findings originate
Building apps — the playbook generated apps are built against