The build flow

Key points

• Type /build followed by the goal, for example "/build a leave tracker".
• TAFI stops for approval after requirements, after the data model and after the build plan.
• At any stage you can approve, keep planning, describe a change, or cancel the build.
• The last stage builds the feature and checks that each screen actually renders on the platform.

Start a build

For anything bigger than a single change, type /build followed by the goal in the TAFI panel. Good requests say who uses the feature and what they need to do:

• /build a leave tracker: employees file leave requests, managers approve or reject.
• /build add a Billable flag to timesheets: extend an existing feature.

For a guided build of a whole new app, use /taf-new-app with the app name. TAFI can also open Studio's New App wizard, where you choose a template and connect a database. Only one build runs at a time.

The stages

• 1. Requirements. TAFI drafts what the feature should do. If your request leaves real questions open, it asks them first rather than guessing. Approve to move on to the data model.
• 2. Data model. TAFI designs the objects, fields and relationships. Approve to move on to the build plan.
• 3. Build plan. TAFI lists every change it will make, in order. Approve to build.
• 4. Build and verify. TAFI creates the objects, queries, screens, access and menu entries, then checks that each screen renders on the platform and reports the result.

The order inside the build follows the platform's dependencies: the app's roles are read first, each object is created with its default queries, access is granted per object and role, screens are generated from the objects' real fields, menu entries are added, and finally records are read back to prove the feature works for a real user.

Steering a stage

Approval is not the only option. At any stage you can choose Keep planning or simply describe a change instead of approving, for example:

• “add a Priority dropdown”
• “drop the Manager screen”
• “make Notes required”

TAFI revises that stage and asks again. Cancel build stops the build. Because each stage is approved separately, a change of mind about the data model is a revision, not a rewrite of something already built.

After the build

• TAFI lists the files it changed and the items it changed on the platform, each with a link to open it in its designer.
• It tells you when part of a change was written to the live app and the rest stayed on your computer until you publish it.
• Run /review at the end of a session. Some screens save correctly but still render blank, so the review checks that each screen really renders, not only that it was saved.
• Everything TAFI built is ordinary app metadata. After TAF: Load latest from platform you can open, run, change or delete it in Studio, and ship it with a release.

Commands that help

• /fix reproduces a bug, finds the cause, previews the smallest fix, applies it and verifies it.
• /debug checks data, screens and permissions against the live app when something is not working. It changes nothing.
• /audit reviews structure and who can see what, and flags access that is too broad or missing.
• /explain and /find describe a feature or locate an object, field, screen or query.
• /memory lists the lessons TAFI keeps: corrections you make and conventions you state for an app. You can remove one or clear them all.

When things go wrong

• “Built as a local draft, publishing failed”. The item exists only locally. Open it in its designer and publish it from there.
• A screen check reports problems. TAFI lists what does not meet the platform's component rules. Ask it to fix them, or fix them in the screen designer.
• A query or screen shows no rows. Try /debug. An empty result usually means the role's Own or Team access scope filtered the rows out, not that data is missing.
• TAFI could not read a stage from its reply. Redo that stage, or reword the /build request.