Every T-Builder release

• A FAQ widget: questions that open to their answers, one repeater item per question with a plus button for the next, written as <details> so it needs no script, reads well for search engines and keeps one answer open at a time when asked. FAQPage structured data comes with it. The converter turns a template's list of <details> into this widget, under a heading or on its own, with the question and answer type and colours of the design.
• Developer and client: the Style tab of T-Builder's own widgets (FAQ, Items grid, Slider, Marquee band) is shown to administrators and to any role given the t_builder_develop capability; everyone else edits the content, the items and the links, and never the look. The t_builder_developer filter decides otherwise when a site needs it.
• A theme built from a conversion carries the FAQ widget like the other shared widgets, so a page keeps its FAQ without the plugin.

• A theme built from a template whose name starts with a digit no longer takes the site down. The theme keeps its name and folder, but the PHP it declares (constants, functions, the namespace) gets a letter in front, so functions.php loads instead of failing on every request.
• Activating a built theme is guarded now, the way activating a written plugin already was: the site fetches its own front page and REST API with the theme active, and a theme that answers a critical error is taken off again at once, with the previous theme back and the reason in the result. The site never stays on a white screen.
• A conversion no longer switches a theme on by itself once a theme T-Builder built was removed from the site by hand: that removal counts as the developer's choice, and the new theme is installed but left inactive until asked.

• Conversion keeps a designed grid: a two-column hero or a text-and-picture row laid out with CSS grid stays two columns in Elementor, each column as wide as its track. A picture that bleeds past its column no longer pushes the next column onto a new line.
• Pictures that fill their box in the design fill their column in Elementor: width 100%, cropped to the box's height as the design did, instead of a pixel width copied from the browser.
• A theme built from a conversion holds a lock while it writes and zips, so two builds of the same theme can no longer empty each other's folder; a missing folder is reported in plain words instead of a crash. The theme is named after the template without the file extension.
• Real photographs in designs: T-Design places a photograph matching each placeholder's subject, fetched once per account and kept in the Library; the site fetches them from the account when the template is installed.

• Licensed, not sold: the plugin's licence is now the Tredcoo Terms of Service (tredcoo.ai/terms) instead of the GPL. It runs only with a site key from a Tredcoo account, verifies that key with the platform on every call, and stops on a site the moment the key is revoked from the account or by Tredcoo. Copying, modifying, redistributing, pointing it at another backend or removing the key check is outside the licence. A LICENSE.txt ships in the plugin and the connect screen links the Terms.
• Public pages for the Terms of Service and the Privacy Policy on tredcoo.ai, including what the agent reads from a connected Google Search Console and how to withdraw it.
• Nothing else changes inside the plugin in this version.

• Semrush and Ahrefs as connections: the agency pastes its own API key on the project's Site tab, the platform checks it with the tool, keeps it sealed and shows the units on the account; the units come off the agency's own plan. With both connected, one is marked primary. A guide under each row says who connects, what plan is needed and where the key is.
• Keyword data in the chat: search volumes, difficulty, cost per click and intent per country with related and question terms; a domain's standing, top keywords or pages and the domains competing for the same terms, or who ranks on page one for a term; backlinks with the strongest referring domains. The agent builds a keyword map from them, reads competitor pages, and writes the pages that should rank. Without a connected tool it says so and never invents a figure.
• No change inside the WordPress plugin in this version; the number moves with the product.

• Connections: a card on the project's Site tab where the developer, or the client who owns the account, connects the outside services the agent may read, each with a short guide: who connects, what must exist first, what the agent does with it. Google Search Console is the first; Google Analytics and Business Profile follow through the same connection. The person signs in on Google's own screen with the account that has the site, picks the property, and can disconnect in one click; Tredcoo never sees the password and keeps the access sealed.
• SEO audit from the chat: "check the SEO" reads the site's public pages the way a search engine does and answers with a score and the findings ranked, each with the fix: titles and descriptions, H1, alt texts, thin pages, noindex, canonical, Open Graph, schema, slow answers, duplicates, https, sitemap, robots, Core Web Vitals. The agent then fixes what it can, page by page, and says what moved.
• Search Console in the chat: once connected, the agent reads what people actually search, the clicks, impressions and positions per query and page against the period before, and the opportunities: queries with many impressions and a position between 6 and 30, where a better title, description or page pays most.
• No change inside the WordPress plugin in this version; the number moves with the product.

• More models to choose from: the platform keeps its model list in step with the newest versions, so a project's Model select offers every model Tredcoo serves, Fable 5.1 among them, each with its price per million tokens.
• Switching a project's model shows the cost first: the price per million tokens, how many times the default it costs, and what the model is for, with a Switch button; nothing changes before it.
• A model that is busy gets one more try: a turn that fails on the model's side is retried once after a moment; when it fails again, the error names the model and suggests waiting or switching.
• What the agent knows belongs to the platform, not to the model: the handbook, the account's and the project's knowledge, the skills and the client's memory are followed to the letter by whichever model runs, a skill line by line as written; and every job that taught something (how a template is built, how a plugin is set up, a fact about the client, a mistake not to repeat) is written down before the turn ends, so the next turn and the next model start where this one ended.
• No change inside the WordPress plugin in this version; the number moves with the product.

• Where to build: when a job fits in more than one place (a form in the site's form plugin, a T-Builder form or a plugin of the site's own; a booking in Bookly or in custom code; a section native, as a widget or in the theme), the agent asks first: the options, the best one for this site and why, marked as the default, and what the developer prefers. It builds only after the answer; the answer is saved in the project's knowledge, so it is asked once.
• The model is the developer's choice: a Model select on the project page (the agent's allowed models, with the account's price per million tokens) sets which model every chat in that project runs on; the default stays Sonnet.
• T-Design with a model of its own and a premium mode: the design form picks the model that draws the page and switches on Premium (a studio-grade brief: a distinctive type pairing, one accent, sections that differ in rhythm, hover and entrance motion, real copy, 9 to 12 sections, a bigger output budget). A design catalogue on the platform describes every marketplace genre and category, what buyers expect in each, the premium marks and the inspiration sources; T-Design reads it on every call, and the form offers three directions per kind from it.
• Project files grouped by kind (templates, notes, documents, fonts, pictures as a grid), each group folding, with a preview in place for pictures, PDFs, notes and templates.
• No change inside the WordPress plugin in this version; the number moves with the product.

• Find where something lives: one call with a few words answers with every place they live on the site (a page or an entry of any content type, drafts included; page-builder data and custom fields; a menu item; a picture by title, alt or file name; an option; a user) and the tool that changes each. "Remove this person" or "change this text" no longer means reading pages one by one, and the agent no longer says something is out of reach before it has looked; words found nowhere are named as coming from a plugin's own table or from outside the site.
• Menus: create or change a classic menu from the chat (rename, theme locations, items as pages, entries or links, nested, appended or replaced, removed by title), and delete one with its items, freeing its locations. Menus a theme demo left behind go when the developer asks.

• Plugin updates from the chat: "update all the plugins" runs the updates WordPress.org offers, one plugin after the other, each kept active; a failed one is named and the rest go on; premium plugins with their own licence are reported as such. The activity log lists every update.
• Installs and updates on hosts that asked for FTP: when the plugin folder is writable but WordPress still asked for FTP credentials (the files belong to another user than PHP runs as), T-Builder writes directly, as FS_METHOD in wp-config would; a host where nothing can be written gets a clear sentence instead of a silent failure.
• Pictures edited in place: a photo that does not match the others (a full-length portrait among square headshots) is cropped, resized or rotated by the agent with media-edit, with the face kept in the frame, under the same attachment id so every page shows the result at once, or as a new picture when asked. No cropping plugin, no round trip to the developer.

• Plugins of the site's own: the agent writes a small plugin when a job needs code the installed plugins do not offer (a shortcode, a custom post type with its archive and single, an integration, a widget, an admin page). It lives in wp-content/plugins/tb-, every PHP file is parsed before it is written, eval and exec are refused, activation runs under a guard, and a critical error on the site right after turns it off again with the message in the answer. Only plugins T-Builder wrote can be read back, replaced or removed; the developer's own plugins are never touched.
• Slider widget: a template's slider (Swiper, Slick, Owl, Splide, a hand-made one) converts to T-Builder's Slider, one slide per repeater item with picture, small line, heading, text and two buttons, with autoplay, fade or slide, arrows, dots, swipe and keyboard; the developer edits the slides in Elementor. Style controls for height, alignment, scrim, type, buttons, arrows and dots. No library; a visitor who asked for less motion sees the slides still, with the arrows.
• Running animations stay: a floating icon, a pulsing badge, a spinning mark no longer turn the whole section into one HTML block. The element becomes its native Elementor widget and carries its animation in the Motion panel's new "Running animation" (the CSS shorthand and its keyframes, editable), printed scoped to that element and switched off for visitors who prefer reduced motion.
• New things look like the site: a new section, page, post type, widget, form or block is built in the site's design (its palette, fonts, buttons and cards), not the WordPress default look; the agent reads the site's styles and the page first, asks one short round of questions when the look, the fields or the place on the site are open, and takes the site's own defaults when told to just do it. When the request needs a design of its own, the agent asks T-Design for a page in the site's look and converts it.
• Forms follow the site: the T-Builder form takes the Elementor kit's primary colour by itself, and the agent sets the rest of its style to the section it sits in; a plugin form gets the site's colours in the plugin's settings or a few scoped rules.
• Items grid widget: three or more like cards side by side in a template (features, services, team members, testimonials, steps) convert to one Items grid, a repeater with picture or mark, small line, heading, text, a line under it and a link per item, with the template's columns, gap, card paint, radius, shadow, type and link style. The client adds a fourth card where the template had three, in the widget, instead of copying containers. Style controls for the grid, the card, the picture and icon, the type and the link.
• Theme packages carry the Slider and the Items grid with their Marquee band, so a page keeps them when the theme stands alone.

• Chats inside a project: a project is what the team shares (the site, its knowledge, skills, files, schedules); a chat is one thread in it. Anyone on the project opens as many chats as they like; a new chat is private to the person who opened it until they share it with the team, and its title comes from its first message until renamed. The chat rail on the project page lists your chats and the shared ones, newest first; rename, share or make private, clear or remove your own. Two people work in two chats at the same time. The conversation a project had before becomes its General chat, shared.
• No change inside the WordPress plugin in this version; the number moves with the product.

• Schedules: standing jobs a project runs on its own. They are set up in the chat: say what should happen and how often ("every Monday at 8, check the site for broken links and mail me"); the agent writes the job out in full (name, instruction, rhythm and time in your time zone, the channels for the report, whether it may change the live site) and adds it only after you agree; the tool refuses to add one without that agreement, and setting one up installs and changes nothing. Every firing is a run of the project in a thread of its own, ending with a report a developer reads in a notification; without the live switch it works on drafts and writes proposals. The project's Schedules tab shows every schedule with its rhythm, state, how often it ran, its last run and where it reports; there you run one now, stop the run going on, pause, resume or remove it, and open its instruction, its runs and its whole thread read-only, with a button that carries the last report into the chat.
• Notifications: Preferences → Notifications keeps an e-mail address, a Slack incoming webhook and a Discord webhook, each with its own switch (e-mail is optional), with a test button; a schedule picks among them, and a channel that is off or not set up is skipped and said so.
• The project page has tabs and uses the whole screen: Chat with the Files and the Library beside it, Knowledge & skills, Schedules, Activity and Site, each with its count; the tab in use is kept for the session and in the address, so a saved form returns to the same tab.
• No change inside the WordPress plugin in this version; the number moves with the product.

• Motion for free Elementor: every container gets Style → T-Builder motion (background parallax with a depth, fade-in), every widget gets Advanced → T-Builder motion (scroll drift up or down with an amount, fade-in with a delay), drawn by one small script of the plugin's own, no Pro and no GSAP; section widgets and the widgets of every theme T-Builder builds get Parallax in their Layout panel, and the theme carries the script. Reduced motion on the visitor's system switches all of it off.
• Theme Settings can sit where the client wants: under Appearance (as before) or as a menu of its own in the sidebar, chosen on the page itself (Identity & brand) or by theme-build with menu "top"; every link to the page follows.
• The T-Builder Form widget has a full Style tab: Fields (background, text, placeholder, border, focus colour, radius, inner padding, typography, gap), Labels (colour, typography, spacing), Button (colours, hover, typography, radius, padding, full width, alignment) and Card (background, padding, radius, shadow, border), so a form matches a design without being rebuilt from loose inputs.

• Saved blocks: elementor-template-save saves any element of a page (a container with everything in it, a section, one widget) as an Elementor saved template, as "Save as template" does; elementor-templates lists the library with where each block is placed; elementor-template-insert puts an editable copy on a page. The new Saved block widget (tb-block, under "T-Builder elements") places a saved template live, one source for every page, which free Elementor had no widget for; [tbuilder_block id=""] does the same in block content. "Make this a widget for other pages" is answered with the block saved and placed, never with re-inserting by hand.

• Forminator joins the form plugins T-Builder builds in: form-save with plugin "forminator" writes the form through Forminator's API (name, phone with international check, e-mail, choice lists, long text, date, number, website, upload), sets the notification to the recipient with reply-to on the e-mail field, the thank-you line or redirect and Akismet, and answers with the link into Forminator's editor; id changes an existing one.
• The agent sets the site's reading, identity and date settings itself (settings-set: front page and posts page, name and tagline, posts per page, timezone and formats) instead of sending the developer to wp-admin; a page becomes the front page once it is published.
• A skill the developer names that is not in the account is said to be missing, with where to upload it, and the job is done with the handbook; a skill that is there is followed step by step.

• Forms in the plugin the client uses: form-save takes plugin ("wpforms", "contact-form-7", "gravity-forms") and builds the form through that plugin's own API, with the fields mapped to its types, the notification to the recipient, reply-to on the e-mail field, the confirmation line or redirect and its anti-spam on, and answers with the plugin's edit link, its shortcode and a shortcode widget to place it; id changes an existing form of that plugin. WPForms Lite gets a text field where a phone, date, website or file field needs Pro, and the answer says so. forms lists every form of WPForms, Contact Form 7, Gravity Forms, Fluent Forms, Ninja Forms and Forminator with edit links, and which form plugins are installed. The earlier Contact Form 7 pair (forms, create-form) is gone; its forms key had been shadowing T-Builder's own tool on sites with Contact Form 7.
• T-Builder → Forms in wp-admin: every T-Builder form with its fields, recipient, entries and placements; an editor for title, recipient, subject, button, thank-you line, redirect, the fields in order (label, type, required, placeholder, options; add and remove rows) and protection (rate, stored entries, e-mail confirmation, Turnstile and reCAPTCHA keys); the stored entries with a CSV download and deletion; the forms of other plugins with a link into each plugin. Every form answer now carries edit_url and entries_url. The T-Builder Form widget points there too.
• The agent builds a form where the developer says or where the site already has a form plugin, never claims a plugin has no API, and answers "where can I see this form" with the link.

• Marquee band, a widget of T-Builder's own under "T-Builder elements": Items (a repeater of texts with optional links), a Separator mark, Motion (loop time, direction, pause under the pointer, still rows for visitors who asked for less motion) and a Band style panel (background, vertical padding, typography, text colour, gap between items, separator size and opacity). Editor and front end render the same PHP; WPML translates the items.
• A moving band in a template converts to this widget with its items, mark, type, colours, spacing and speed read off the design, so the editor shows a list of items instead of a block of HTML.
• Every theme T-Builder builds carries the widget and its stylesheet, registered only where the plugin is absent, so a page keeps its band when the theme stands alone.

• Every conversion makes the site a theme of its own, at once (account preference "A theme of its own after every conversion", on by default): one Elementor widget class per section, the design's screenshot, a description, author and tags in style.css, header.php and footer.php drawing the design's header and footer widgets, and a Theme Settings page under Appearance (Identity & brand, Colours, Typography, Layout & motion, Header, Footer, Contact & forms, Demo content, Live preview). The theme's colours and fonts lead; a section's own Style tab overrides them for that section. Installed at once; activated when the site still runs a default theme or one T-Builder built before, otherwise left installed with an offer to switch.
• Section widgets are named and iconed by their role (Site header, Hero, Feature grid, Figures strip, Steps process, CTA banner, Contact panel, Site footer, or the section's eyebrow: "Core values"), without the library prefix. Controls are grouped by what they are: Background (a picture or video laid over the section, darkened by a Scrim strength slider), Eyebrow, Heading, Body copy, Texts, Buttons, Images, repeaters named by their items (Stats, Cards, Chips, Menu links, Logos); Layout with Minimum height. The render service draws a screenshot of every page (1.3.0).
• The theme's Live Preview shows the design's home page instead of the site's old front page, until the site has a front page built from the theme; Theme Settings → Demo content makes the converted page the front page with one click (published and set as the front page), and a note after activation points there.
• Native Elementor, closer to the design: a wordmark (a few letters with a small picture set among them, a logo drawn in type) stays one piece on one line instead of a stack of boxes; a picture filling a section from behind becomes the section's own background (Style → Background) and scrims laid over it stretch with the section, under the content; a translucent ornament keeps its opacity through the background overlay, a pattern tile keeps its size and repeat, a layer set from the right or bottom edge stays anchored there, and one fading out through a gradient mask keeps the fade; a marquee keeps moving (its own keyframes, paused under the pointer, still on one line); boxes without a gap in the design get none instead of Elementor's default 20px.
• A page the site already publishes stays published through a conversion again, so a front page never turns into a draft behind the visitor's back.
• site-reset: trashes the importer's drafts (published pages when asked), removes every section and app widget from the Elementor panel, the fetched templates and the themes T-Builder built (the earlier theme comes back), so "start over" is a clean slate.

• A converted page can be delivered as a theme of its own: theme-build (includes/class-theme-package.php) packages the section widgets of the drafts named (or of a whole template) as a WordPress theme with one real Elementor widget class per section, in plain PHP an agency can read and keep: Content controls for every text, picture and link, Style controls for colours, fonts and spacing, the design as the defaults; a shared base class, a loader, functions.php, minimal templates and a canvas template, one scoped stylesheet per widget loaded only where the widget is used, the entrance script, the design's own font files, a demo JSON with every widget at its defaults, a README. Zipped under uploads with a download url; install copies it into the site, activate switches to it. Editor and front end render the same PHP. The agent's prompt says a skill asking for a custom theme, a theme package, widget classes or a zip is delivered this way, never sent to another tool.

• A site connected before 0.9.11 joins WordPress's auto-update list with its first version report, so one update by hand is the last one.
• Billing: Credit, Usage and Invoices are one place in the account menu, with three tabs; the Credit tab shows the balance over the last movements as a chart, the Usage tab the month day by day per product.
• Library: the Files tab shows its cards again (the T-Design form had swallowed them); the T-Design composer is light and left-aligned like the rest of the account.

• T-Design is a tab of the Library page, next to Files: a composer for the brief, a plus to attach a template from the library (redesign it, or take a new idea from it), a style, the pages and the name, and a choice of what it should be: a one-page website, a multi-page website, a landing page, a web shop, a portfolio, a restaurant, an agency, a blog, an event, or blank. The kind and the style go into the design.
• Skills have a scope: the account's general skills on Preferences, a project's own on its page; a project skill with the same name replaces the general one there (customer_skills unique per scope, Skills.forProject). The agent's "learn this as a skill" saves to the project unless told it holds for the whole account. A skill can be uploaded as a file: Markdown, or a .skill file (a zip with SKILL.md and its references), on Preferences and on a project page; the name comes from the file. A skill holds up to 40 000 characters.
• Usage is shown per product (T-Builder, T-Design, later T-Marketing) with tiles and a day-by-day chart; credit movements show one line per step.

• Users: users (the site's users and roles), user-create (login, e-mail, role; WordPress mails the person a set-password link and the tool returns the same link, valid 24 hours; no password is ever chosen or shown; the e-mail is checked first), user-update (role, e-mail, names; reset for a fresh link) and user-delete (content moved to another user). The connected administrator cannot demote or delete themselves. Module switch "Users" on Preferences.
• The account learns a new version the moment it runs: the plugin reports its version and tools when it is activated, right after WordPress upgrades it (by hand or in the auto-update run, with no admin present), and on the next page load until the report went through; a failed attempt is retried a minute later instead of being marked done.
• Engine: a marquee track that carries its items twice shows them once, wrapping; a header's menus and buttons are as wide as they are and never shrink a link into two lines.
• Platform: a run can be stopped from the chat (the send button becomes Stop while a run goes on; the runner halts before its next model call or tool call, nothing more is spent, and the message comes back into the composer to be corrected). A reference tool gives the agent a WordPress and Elementor developer handbook (widget classes with Content and Style controls, repeaters, hover tabs, editor-safe JavaScript, theme structure, hooks, post types, REST, security, performance, RTL, pitfalls, the Elementor data model). Web addresses in answers are links. T-Design on the Library page designs a site from a brief, redesigns a template in the library, or takes an idea from one, in one metered model call (platform/Services/Design.js), and saves it to the library as a template the converter reads (pages as data-page groups, shared header and footer). Library uploads take a name. Each template on the project page offers "To Elementor" or "Keep as HTML". Skills have a scope: the account's general skills on Preferences, a project's own on its page; a project skill with the same name replaces the general one there (customer_skills unique per scope, Skills.forProject). Usage is shown per product (T-Builder, T-Design, later T-Marketing) with a day-by-day chart; credit movements show one line per step.

• Templates convert to Elementor's own elements. The engine's new native builder (converter/lib/class-native-builder.php) rebuilds every section out of flex containers and Elementor's heading, text, image, button, icon-list, video, divider and HTML widgets, with the typography, colours, paddings, gaps, backgrounds (colour, picture, gradient), borders, radii and shadows the browser measured on their settings; rows keep the widths the browser drew and stack on a phone; big type scales down on tablet and phone; entrance animations become Elementor's; decorative layers laid over a section (line art, a gradient) keep their place with Elementor's position controls; a row of links is a row of link buttons; a menu wrapper that is no box (display:contents) is opened up. import-convert builder "elementor" (the default) does this; "sections" keeps every section as one section widget as before. A section with a working form, a running keyframe animation or an icon font stays a section widget, and the answer says which and why (native_sections, kept_as_section_widgets); template-scan marks each section native or kept_why. The template's own font files are declared on the page and in the editor (_t_builder_faces) and listed in Elementor's font menu. Render 1.2.0 measures every flex and grid item (data-tb-w) so the native layout has the numbers.
• The plugin keeps itself current: at connect it puts itself on WordPress's own auto-update list, so a release from the account installs in the site's twice-daily update run without anyone opening the plugins screen. The screen shows "Disable auto-updates" and that choice stands. The cached release answer is dropped after any plugin update.
• Platform: a template page drawn by an older render capture is drawn again before a scan or a conversion. The drawn copy carries meta t-builder-render; the platform asks the render service its version (1.2.0 now) and redraws what an older one drew, so a fix in the drawing reaches templates drawn before it.

• A prototype that holds several pages in one file (a design tool's export with page variants) is recognised. template-scan lists a group per section, the file's groups with their section numbers, the shared sections (header, footer) and the parts already made. import-convert takes sections and title and makes those sections a draft of their own (Importer::part); the other groups' widgets stay in the library, so one file becomes Home, Products, Contact, each its own page.
• Sections drawn over the page (a menu overlay, a modal, a bar fixed to the bottom edge) are flagged overlay and left out of a page draft; they come only when named in sections. A header fixed to the top stays.
• Prototype branches that are off at rest (hint-placeholder-val="{{ false }}": a thank-you state, a quote bar, a mobile-only block) are skipped by the engine, while page variants keep their sections. The page cleaning now keeps hint-placeholder-val and data-page, data-screen, data-view, data-route, so the engine sees them.
• The scan counts placeholders per section: "{{ … }}" texts the prototype fills from data the export does not carry, with a note to ask for the real texts and write them in with elementor-edit.
• Section widget numbers follow the widgets kept: the number the scan shows is the number in the slug, so dynamic and sections name the right ones (before, an empty section left a gap).
• Render capture: an SVG laid over its box keeps its position and layer, so a hero's line art no longer pushes the content down; a design tool's branch element (sc-if, sc-for) is display:contents, so a header's row stays a row.

• Forms are first-class site data (includes/class-forms.php, option t_builder_forms): a form is a titled list of typed fields (text, email, tel, textarea, select, checkbox, radio, date, number, url, file) with a recipient, a subject, a thank-you line, a button label, an optional redirect and its protection. It is placed with the new Elementor widget T-Builder Form (tb-form, category "T-Builder forms": pick the form; recipient, thank-you line, button label and redirect per placement; accent, text and input colours, radius and spacing as variables on .tb-form) or with [tbuilder_form slug="…"].
• Every entry posts to admin-post.php?action=tbuilder_form and is checked there: CSRF nonce, honeypot, a rate limit per address (5 a minute unless the form says otherwise), Turnstile or reCAPTCHA verified server-side when keys are set, every field by its type and length, choices against their options, files only pictures or PDF up to 5 MB into a private folder under a random name. Then it is mailed (Reply-To the sender), kept as a private tb_form_entry when the form stores entries, and reported as form.entry. A mistake sends the visitor back with the reason next to the field; nothing dies. With e-mail confirmation on, a 6-digit code goes to the sender first and the entry waits, for 15 minutes, until the code is entered.
• Tools: forms (every form with its fields, protection, entry count and where it is placed), form-save (from a field list the agent writes itself after a sentence like "a quote form with name, company, email, phone, message and a file upload", or from html, a <form> markup string parsed into fields), form-from-section (the form inside a converted template section as a standalone form, its labels, types, required flags, select options and button read from the section), form-delete, form-entries (stored entries, newest first). The Contact Form 7 tool create-form stays as it is.

• A template page that still needs drawing is drawn by the platform's render service the moment it is scanned or converted; no button anywhere.

• Entries can be removed and pictures replaced, from the second report in the admin (the agent found a team member but could only send the developer to the trash button): entry-status trashes, restores or unpublishes an entry of any type; entry-image sets or removes a featured image from an attachment, an account file or an address; media-list searches the media library; media-replace swaps the file behind an attachment while keeping its id, so every page and widget shows the new picture at once.

• Every content type, not only pages and posts: content-types lists what the site has (team members, testimonials, services, products…) and posts lists a type's entries; page-content, update-page, page-meta-get, page-meta-set, elementor-tree and elementor-edit accept any entry the developer may edit, and create-page-draft takes a type. Learned from the first report in the admin: a team member kept by a theme's own Team type could not be renamed because the tools only knew pages.

• page-meta-get no longer returns _elementor_data (a whole page of builder data, tens of thousands of tokens the agent could not act on); it names the element count and points to elementor-tree and elementor-edit.

• Two tools for Elementor pages, for the case where the agent found three placeholder team members and then asked the developer to delete them by hand: elementor-tree reads a page as a compact tree (ids, types, a gist of each element, repeater items, with a query) and elementor-edit changes it element by element (remove, set, duplicate, move, insert) without rewriting _elementor_data.

• Files leave the plugin. The account holds them (a general library per account, and per project: templates, notes, images, fonts, documents); the site fetches a file when the agent asks for it. Removed from the admin page: the Project files card with its upload form, the account list, the drawer preview, the convert and render buttons and the section switches, with their handlers (tbuilder_import_upload, tbuilder_import_delete, tbuilder_template_fetch, tbuilder_template_save, the ajax tbuilder_import_start, tbuilder_section, tbuilder_import_render), assets/admin.js, the ?tb_frame admin-bar filter and the transient t_builder_account_templates. Settings is one column: Connection, Your project, Requirements, Update, This site.
• account-templates is account-files: "list" shows the files of the account's library and of this project with their role (template, note, image, font, document, stylesheet, data), id, where they are and the import id when already on this site; "add" with file fetches one of any kind (a template scans and converts as before, a note is read with project-files, an image lands in the media library, a font, stylesheet or document is served by its url); "keep" with import keeps a file of this site in the library.
• Importer::receive(), MAX_UPLOAD, the browser upload path and Connection::upload() are gone; from_account() accepts every kind the importer knows and says "file" in its errors. The manifest names fonts, stylesheets and documents by a url the web server serves (Importer::asset_url()), carries the account id of every file and calls the date added_at.
• ?tb_file serving stays: the app widgets' frames need it.

• After an install or an upgrade the site reports its tools, executor address and callback secret to the account on the first admin page load (once per version), so a project can reach the site without anyone pressing "Check connection" first.

• The plugin keeps only its connection: the Tools list, the credit and the Disconnect button are gone from the site (switch tools and block keys in the account), and the Activity tab with it. Every change the agent makes on the site is reported to the account (POST /v1/activity) and listed on the project page; the site keeps no log.
• Requirements are Elementor only. The Abilities API and the MCP adapter are no longer used: the platform calls the executor directly, so WordPress 6.9 and the adapter are no longer asked for.
• template-read with what: fonts also reads the drawn copy: the families the browser really used and the faces the page shipped, and it sees @font-face rules inside an app bundle's script strings.

The rebuild: the plugin is a thin executor. The agent (the chat), its knowledge, its skills and the site profile moved to the account on tredcoo.ai; the platform runs the agent and calls the site's tools. Nothing waits on the site any more.

• POST /wp-json/t-builder/v1/run (includes/class-executor.php) runs one tool per signed request as the administrator who connected the site; GET /ping answers with the version. Signatures are an HMAC over time, method, route and body with a callback secret the site generates on connect and hands over in POST /v1/abilities; a site connected before 0.9.0 gets its secret on the next check, with no reconnect. The site key itself never leaves the site.
• Removed: class-chat.php and both chat routes, class-skills.php and the skills tool, class-profile.php with the profile and profile-update tools, the setup wizard, the model choice, the conversation export, the chat shortcuts; the options t_builder_chat, t_builder_chat_ref, t_builder_model, t_builder_job_*, t_builder_profile, t_builder_skills, t_builder_scan, the transient t_builder_account_skills, the user meta t_builder_job.
• New tool context, first in the list: the site (plugins as names), the toolbox lines, the project files (notes to 3000 characters) and the plugin version, so a turn starts with one read.
• New tool template-read: the template's original upload (the rendered copy when the original is gone) as its head, its @font-face blocks, font links and font families with counts, its colour variables and the 30 most used colours, a text or regex search with context, or a raw slice; linked stylesheets inside the upload count; every answer capped at 20 KB. Learned from a client's chat where the model said it had no tool to open the raw file and asked for CSS to be pasted.
• template-scan adds fonts, tokens (accent, background, heading, body, font_heading, font_body) and faces (families the template ships) per widget, straight from the engine's definitions.
• Self-updater (includes/class-updater.php): GET /v1/plugin/latest from the account, cached six hours in t_builder_latest, offered through update_plugins and the "View details" window; "Check for updates now" on the Settings tab.
• /v1/me may carry project { id, name, url }; the Settings tab shows a button to the site's project on tredcoo.ai, or the sentence to create one.
• Admin page: Settings (connection, project, tools, requirements, update, site facts, project files) and Activity. Header: plugin name, site name, version.
• T_BUILDER_REST_URL in wp-config.php names the address the platform reaches the executor at when that differs from the site's own REST URL (the Docker test site).

On a LiteSpeed shared host the site's background request was ended by the host about a second into every second model call, with no PHP error, while the browser's copy of the turn went on.

• The model call no longer waits inside PHP. The site starts it on the platform (POST /v1/messages/async) and the browser drives the turn in short steps (POST /chat/jobs/{id}/run): each step collects an answer that is ready, runs the tools it asked for on the site, and starts the next call. No request lasts longer than the tools it runs, so hosts that end long or abandoned PHP requests (LiteSpeed, Hostinger) cannot cut a turn. The site never calls itself any more.
• Steps are locked one at a time; a step whose connection was cut is retried by the browser without running twice.

A first turn on 0.8.0 could stop after the second tool round.

• One runner per turn: the site's own call and the browser's cannot both run the same job (an atomic lock in the options table).
• A turn the server ends mid-way (a PHP error, a time or memory limit) is written into the job with what was running at that moment, shown in the chat, kept in the history and in the account's conversation copy, instead of a silent stop.
• The progress poll is never cached: Cache-Control: no-store and a changing query string, for hosts whose page cache also caches REST answers.
• site-health loads the admin-side update, plugin and theme functions it needs in a REST call and runs each test on its own; a test that throws is reported as skipped instead of failing the whole check.
• WPML: every section widget's texts, links and repeated items are registered for translation (wpml_elementor_widgets_to_translate); RTL was already carried from the template.

Seen on a single-file app export (with a video hero, entrance animations and its own fonts): the page came out still and the chat ended in an error page.

• Chat turns run as a job on the site: the browser follows it (/chat/jobs/{id}) and shows every tool as it finishes; a host that cuts long requests no longer ends a turn in "Unexpected token '<'". The site starts the job by calling itself; when a host blocks that, the browser runs it and keeps following. A reopened page picks a running turn up again.
• Answers may be 16 000 tokens long (was 4 000); an answer cut off by the limit is continued in smaller steps instead of ending as "(no answer)".
• Motion comes along: the template's entrance animations (direction, order, delay, duration, read from what the page did while it drew) play once when the section comes into view (assets/section.js); hover looks are probed with a real pointer on every button, link and card and become :hover rules with the template's transitions; running animations (a marquee, a pulse) keep their keyframes, scoped to the widget.
• Fonts are the template's own: the faces the drawn page really used are read from the page itself and served from the site's uploads folder, so a font is never a Google look-alike and never depends on Google being reachable. Google Fonts remain the way for templates that ship no face, now with italics.
• Video and map frames (YouTube, Vimeo, Google Maps, OpenStreetMap) and <video> elements are kept as swappable fields; a hero video plays as it did in the template.
• Rigid flex items keep their measured width as a minimum, and a span or link laid out as a block stays one: a logo no longer wraps when a font is a pixel wider on the site.

• Template pages are drawn by the platform's render service (headless Chromium, render/) instead of the developer's browser; the Project tab no longer has to stay open, and the same capture works from the website later.
• Every upload becomes the site's working copy on the platform (x-kept: 0), pruned after seven days unless kept in the account; "Keep in my account" promotes it without a second upload.
• Multi-page: drafts are made for all selected pages first, named after their files, so links between pages resolve; a re-conversion fills the same draft in place.
• frame.js is app-mode only; the capture script lives in render/capture.js.
• The setup is optional after the connection step: "Skip the rest, open the project" in the wizard, the tabs open as soon as the site is connected, and a soft reminder on the Project tab links back to the setup. The chat asks for what it still needs when it needs it.
• The switches per tool moved to the account: the site reports what it can do, the website shows a switch per tool per site, and the plugin registers only what the account allows. Standing rules, the dynamic-sections default and the library name come from the account's Preferences.

• The template engine runs on the Tredcoo platform: the plugin sends a rendered, prepared page and installs the section widgets that come back. Nothing worth copying stays in the plugin.
• Templates in the account: keep a template from any site, add it to any other connected site, from the Files card, the chat (account-templates) or the website account.
• Every page with a stylesheet is rendered in the browser before conversion.
• SVG image files inlined with their viewBox; icon fonts as real glyphs; the template's own font faces served from the site; image sideloads matched by content hash.
• Widget names scoped to their upload; a re-conversion replaces only that page's widgets; clean page titles; placeholder on dynamic frames.
• Security pass: sandboxed template frames served by the plugin, CSS validator, per-user chat history, redacted conversation copies, throttled public forms, admin-only checks and exports.

• Setup wizard, profile, requirements, way-of-working skills kept in the account.
• Elementor-only conversion into section widgets with grouped controls, repeaters and working forms; dynamic sections as sandboxed app widgets.
• Conversation copies on the platform, export from the Activity tab, toolbox.

• Connection with a site key, site profile to the platform's memory, MCP abilities, first template imports.