craft-anything/docs/STATUS.md

Status

What works today and how it was checked. The plan, owners and order of work are in ROADMAP.md. Last updated 2026-11-02. The baseline audit on 2026-10-23 from main had 923 tests passing; workspace clippy, layers, fmt and the secret scan of all history were clean. Chinese UI checks are listed separately below.

What works, and how it was checked

Area	State	Verified by
Mach-O Objective-C pointers	Chained offsets mapped only into file-empty __PAGEZERO reach the image-base fallback; pointer candidates must be backed by file bytes	Synthetic thin and fat Mach-O regression, plain-pointer and authenticated-rebase controls, null and unmapped-pointer checks. Real binaries were not checked for this correction
Apple app graphs	Selecting a macOS bundle recognises its root-relative Contents/Info.plist and retains its service/extension type; nested XPC bundles appear in services and as xpc-service graph nodes, including their executables when hosted in frameworks	Synthetic inventory tests, including parent-directory and flat bundle layouts, selected services/extensions, framework-hosted service executables, and bare-program controls. Ordinary selected directories with Contents/Info.plist need an Apple bundle suffix; archives retain layout-based recognition. Framework libraries and dylibs stay excluded from executables. Real app bundles were not checked for this correction
Chinese UI	Simplified (zh-hans) and Traditional (zh-hant) Chinese in Settings → General → Language; System chooses a supported OS language, otherwise English. Both catalogs cover UI controls and tool titles; translated titles are searchable. Raw tool data, AI text, logs, CLI/MCP and the separate browser viewer keep their original text. See localisation.	Catalog integrity and locale-resolution tests; cargo xtask i18n-coverage; isolated UI language-switch test. Platform visual checks are recorded separately.
Engine	298 engine tools (314 with the AI and setup layers') across native, managed, Java, Android, Apple, JS/Electron, web, firmware, packets, databases, game archives and assets; see tools.md and tool-status.md. A saved result can be narrowed without running again (core_evidence_browse keeps the rows matching given field values, cut to chosen fields)	A functional audit that ran every tool on real inputs on Windows, plus 600+ unit and integration tests
Single-file apps and game files	core_packed_files_list and core_packed_files_unpack read Bun and Node.js single-file programs, .NET single-file apps, PyInstaller and Godot packs through one seam (formats::packed); formats_bytecode_show reads Python bytecode, game_unity_code_names_show Unity IL2CPP metadata, formats_ai_weights_show GGUF and safetensors headers. app_folder_explain says what an install folder is made with and what to run next	Unit tests with damaged files. Real files: a 279 MB Bun program, Node blobs, PyInstaller programs (Python 3.9, 3.14), .NET 8 single-file apps (macOS, Linux, Windows, compressed), Godot 3.6, 4.3 and 4.5 packs, 214 Python modules against CPython's own reader, a GGUF and a safetensors file, about 25 installed Mac apps. IL2CPP on synthetic files only
Program facts across builds	native_library_calls_list (delay-load too), native_offered_symbols_list, native_publisher_show (checks the file hash and the signature, not Windows trust), app_builds_line_up pairs functions across two builds and says how, native_source_folder_write writes pseudo-C to a folder and picks up where it stopped, android_components_list	Unit tests. Real PE, ELF and Mach-O files; two builds of a 276 MB program; a signed Microsoft DLL; Android components from one real APK, spot-checked
Stand-in backends	web_standin_build turns a HAR into standin.json (secrets dropped, varying path parts templated); web_standin_start answers from it on loopback; web_standin_show lists what it had no answer for. Writes replay what was recorded and don't change later reads. App maps list GraphQL and tRPC operations; web_walkthrough_check checks a scripted session without a browser	Unit tests, real loopback requests, and a run with curl on a hand-written HAR. No browser-made recording or real front end yet
Websites as targets	web_site_open keeps a private browser for the session and every browser tool inspects that page; web_site_capture records screenshots at each width (desktop, tablet and phone), rendered HTML, design tokens (colours in hex, spacing, content widths), the CSS breakpoints, the layout at each width (page width, heading sizes, each section's padding, gap, content column and items per row), page health (script and console errors, failed requests) and an accessibility outline, layout outline, assets with font files and requests, links and form outlines. In Clean room the capture keeps only what a visitor sees (no HTML, CSS rules, scripts, requests or errors), and opening a site reports no load errors	Live run on example.com; unit tests
Rebuild workflow (Study → Build → Check → Refine)	crates/ai/src/rebuild/ (kinds, checks and stacks are pluggable: docs/extending.md). Three kinds: website, app, game (a project whose stack is a game engine is always a game). The request decides how to build: a language, framework, engine or platform it names wins over the kind's default stack (Rust + egui for apps, Unity for games, the original's for websites), and the build check, the recorded stack and Play follow what was built (an Electron app opens in its own Electron). Websites: Study also captures up to 4 other pages of the site; menus are opened on a computer and on a phone; the check serves the build on loopback and compares every page at 1440, 768 and 390 px (likeness = mean of layout and perceptual detail, SSIM, averaged over pages, leaving out the parts of the original that change by themselves, found by photographing it three times; the note adds text, page structure, the colours, font, text sizes and spacing the build misses, and per width a page that scrolls sideways, heading sizes and sections whose padding, items per row or content column differ, the errors, failed requests and accessibility gaps the build adds, and the opened menus and pop-ups). A stack or library named in the request (Next.js, shadcn/ui, Tailwind CSS…, stacks.toml) is what the builder uses; with none named, a website's stack is the builder's choice (told to match what the original is built with) and the stack it used is recorded from app/package.json. The builder leads: it studies, asks the tools follow-up questions, records what it can't find out as unknowns (core_unknown_add; the run reports the open ones), and tests its own build mid-turn with rebuild_check (the same checks, for every kind); a check with anything it couldn't compare, or any claim that fails (a website page that scrolls sideways, logs new errors, fails to load a file, lacks a landmark, or a menu that doesn't open; for games each self-test step, for Deep-mode sheets each original number in the code, for console apps the same exit and output as the original's runs), isn't good enough; apps and games by whether they build. Up to 6 refinement rounds, or until a website reaches 90% likeness. A turn cut off by a time limit, crash or dropped connection resumes (up to 3 times); builder turns may run 24 h	Unit tests for prompts, stack choice, site detection, feed folding; live runs reached Build and decompiling (below)
Games	Engine detection for 12 engines (Unreal, Unity, Godot, Source, GameMaker, RPG Maker, Ren'Py, MonoGame, LÖVE, CryEngine, Cocos, Cube) with versions. Unreal and Godot games are rebuilt in the same engine, others in Unity; installed engines are found, Godot installs itself, others get guided installs. Picking an inner folder (Engine, Binaries, Paks…) finds the game's folder. Just look inside a game shows what it's made of (core_target_triage on its folder: engine and version, how its code ships, the libraries its Unity assembly names give away, its own code, scenes and size) and opens it in the chat to ask about it. The builder keeps app/MECHANICS.md and its structured twin app/mechanics.json (checked after each build), in Deep mode only, may reuse the original's readable files for private use (never decrypting; generated pictures and 3D models replace its art when the person turns them on; Clean room copies none of its files), lists them in CREDITS.md (checked, with the private-use line in README.md); a game is ready only when its --self-test shows the player moving, acting and the HUD drawn, and the result can be started from the project page	Unit tests; live runs on Windows
Clean room and Deep mode	Clean room (the default) runs only the tools in engine/src/clean_room.rs: ones that touch no target or watch from outside (the website as a visitor sees it, pictures of a window, its controls, recorded runs, a phone's screen). Every other tool, a plugin's included, is refused in the app, CLI, MCP and agents, with a way to turn on Deep mode. A Clean room build studies an app or a game only from the person's pictures and words (and a picture of its window when runtime study is on); its builder's reads and commands go through an approval rule that keeps it out of the original's folder and site (with Claude Code, and with ACP agents for what they ask about; other agents aren't held to it, see roadmap R2.2). Deep mode (deep_mode in Settings, --deep for one CLI run) uses every tool: the builder sees them all, and a website's study also reads its JavaScript and watches its start page for ten seconds (capture/how-it-works.md). Ghidra adds its decompiler in Deep mode when it's installed: it is found, or installed after asking. Study starts one analysis of the main program, saved and shared with the builder's tool server through a lock file (up to 8 h, Java gets half the machine's memory or the amount set in Settings → Engines, 4 to 31 GB, four slow passes skipped). The builder must decompile before the build is checked; addresses the built-in analysis can't place go to Ghidra, which makes a function on demand (for this run only) where its analysis has none, e.g. code reached only through tables of pointers. Without Ghidra, Deep mode uses the built-in engines	Live runs with Ghidra 12.1.4 on Windows (a shared analysis, and a decompile in seconds on a large program). The guided install of Ghidra and its Java is offered on Linux and macOS too, but has only been tried on Windows. Clean room and Deep mode: engine, AI, MCP, CLI and app tests; no live Clean room build run yet
Auto mode	Settings → Safety, on by default. Builder actions go ahead without asking, except a fixed set that is never done unasked (deleting outside the project, system changes, publishing…); questions get "decide yourself"; asset spending stops at the budget	Unit tests
Generated assets	Off until the person turns them on for a game (the switch on Make and on the project, project_assets_allow, rebuild --generate-assets, saved in craft.json; turning it on without a fal.ai key asks for one); the brief and the asset tools need both that and a key. assets_image_generate (Nano Banana Pro by default) and assets_model_generate (picture → Tripo P1 low-poly GLB with a face limit) through the person's key for each asset provider (fal.ai today); per-project budget, $5 by default ([assets] budget_usd in config.toml); models and prices from the assets.toml table (picture model selectable: Nano Banana Pro, FLUX dev or schnell; priced per picture or per megapixel); every call reports its cost	Unit tests; a live 3D generation with a real key (picture, then model) with FLUX dev; Nano Banana Pro not yet run with a real key
Claude Code builder	Runs the person's own claude in headless mode (Opus 5.5, high effort unless configured) with our MCP server, a permission-prompt tool and core_person_ask; preflights for our CLI (a build stops plainly if it's missing or won't start) and sign-in	Argument and stream-parser tests; live preflight; live builder turns; see claude-code.md
Agents over ACP	Opt-in per backend (acp = true): Gemini CLI, Qwen Code, opencode and goose in their ACP mode, one agent process per chat or build with our MCP server. In chat, permission requests become consent questions; in builds they go through the same approval policy as Claude Code's (inbox, Auto mode)	Protocol unit tests against scripted agent messages and an approval-policy test; not yet run against a real agent
WASM plugins	With --features wasm-plugins: [[plugins.wasm]] components exporting craft-anything:plugin/tools add tools, and ones exporting craft-anything:plugin/checks add checks run after each kind's own (they get the build's file list as JSON) (added, listed, turned on or off and removed in Settings → Plugins or with plugins_add/plugins_remove/plugins_list); no imports, fresh instance per call, fuel and memory limits	Tests with components written in WAT (describe, call, checks, a looping call stopped, imports refused, end to end through the engine); examples/wasm-plugin-wordcount built from Rust and loaded
Questions and approvals	A file inbox per project; core_person_ask, core_action_approve and MCP consent requests become cards in the app	Cross-handle round-trip tests, a full approval round trip through the engine
Desktop app	Simple mode: sidebar with New project and the project history (kept across restarts); New project either makes something or just looks inside an app or file, a website or a game's files; a Game files screen (a game's archives; pictures from Unreal paks, Unity .assets files and Unity bundles saved as PNG after the person confirms they may unpack the game; uncompressed textures and the block formats DXT1, DXT5 and BC4–BC7), make prompt with picture attachments and, for anything recreated, a Clean room / Deep choice (also in the title bar; in Clean room, Just look inside, Game files, opening a file and the workbench ask for Deep mode instead), project screen (steps with the time spent and the AI cost and tokens of every build, saved in the project's usage.json by the run (a coding agent's figure is shown as an estimate at API prices, not the bill), what the build is on now and its activity as it arrives (kept in build-activity.log), pinned builder checklist, feed, question and approval cards, a Continue card when a build was paused or stopped part-way (the app or computer closed; the project shows Interrupted) that carries on the builder's own session instead of starting over, and "It's done" beside Continue or Try again to keep the build as it is (project_build_finish), checks with screenshots and the requirements not met yet, the builder's open questions, preview, play, folder, follow-ups while it builds, which Claude Code takes at its next step; Up in the prompt box takes back the last note still waiting). Projects can start in a folder the person picks, whose files are either the app, edited in place, or material to start from (asked, or the answer remembered in Settings), and are listed from any number of folders (project_folders, project_list, rebuild --project-folder). Make says which AI builds ("Built by": automatic, or any AI that can build, by name); a pick stays with the project and builds its later changes. With nothing to build with, Start offers the coding agents found on the computer. Settings → AI turns an AI off or removes it. In the prompt box, Up at the very start and Down at the very end go through earlier prompts when no note is waiting. Questions about a build ("Just ask" under the prompt box, or a message starting with /btw, the first slash command; rebuild_question_ask) are answered in the conversation, where each folds away and is kept in the project, without a build or a round and changing nothing: Claude Code answers from a read-only copy of the builder's own session. Under each project's prompt box, "Builder's questions: Ask me / Decide yourself" chooses whether the builder's questions come to the person as cards or are decided by the builder, which says what it chose (project_questions_set; the default is in Settings and follows Auto mode until picked). Projects can be renamed, duplicated and deleted (right-click in the sidebar, or the project's page; a delete keeps the person's own files). A build can be pinned (Pin this build on its page, or project_pin_* from the CLI and MCP): a frozen copy in the project's pinned/ folder (the default) or a light one that shares dependencies and media with the project through hard links (each one's size shown first), opened from the sidebar's collapsible Pinned section (icons with a running dot when folded); a pin or Play runs once per folder unless another copy is asked for, and a start that quits at once says so with its last output. Typed drafts survive a restart. In a narrow window the sidebar folds to icons and the project's details move above its feed; messages float over the screen and errors stay until dismissed. Advanced mode: workbench with every panel wired to real tools, as a screen beside the projects (builds and their questions stay a click away)	UI unit and smoke tests (egui_kittest), offscreen snapshots of every screen
CLI	Every tool, --deep or --clean-room for one run (never saved), rebuild (including --continue-in, and --resume to carry on a stopped build), mcp --inbox, ai, setup, doctor, report	CLI integration tests
SQLite database files (db_sqlite_show)	A rowid alias column (INTEGER PRIMARY KEY, including the table-constraint form) shows the rowid; DESC, non-INTEGER and composite keys keep their stored values	Hand-built fixtures; generated files compared with the official SQLite library

Linux Unreal setup

Unreal installations registered in ~/.config/Epic/UnrealEngine/Install.ini are found on Linux. A valid absolute UE_ROOT selects an installation explicitly; an invalid override falls back to registered installations. The version comes from Engine/Build/Build.version, and C++ readiness checks for the selected engine's bundled Clang, not an unrelated system compiler or another installation's SDK. The Linux requirements summary (Builder::needs for Unreal) now describes the bundled Clang toolchain. The guided installer still shows Visual Studio instructions when Clang is missing; platform-specific guidance in that flow remains a follow-up.

Checked with isolated registry and SDK fixtures and with a native Fedora install of Unreal 5.8.4. Readiness is a tool-presence check; a complete Unreal game build and SDK compatibility validation have not been run for this change. Windows and macOS detection retain their existing tests, without new live runs on those platforms.

Fixed during the audit

Web tools couldn't launch a browser on Windows/macOS (Chrome/Edge are off PATH) or be pointed at a URL; the desktop app looked tools up by ids that didn't exist (website, phone, imports, classes, modules, pseudo-C, disassembly, source and network panels were dead); evidence wasn't reloaded from a project in a new process; report citations were unresolved; the CLI's --format clashed with tools' own format; raw binaries couldn't be opened from the CLI; function discovery claimed complete coverage when capped; .NET/Go binaries were called "stripped"; Windows path separators and CRLF checkouts broke two tests; decompiler tail calls and Win64 stack arguments. Added since: byte search, Rust binaries, Electron fuses, WASM interface diff, packet captures, objdump, rizin commands, GDB sessions, then rizin debug sessions (native_rizin_session_*, checked with Rizin 0.9.1 on Windows) and radio decoding with rtl_433 (radio_recording_decode, radio_decoders_list, checked with rtl_433 25.12 on Windows) and Cutter sessions the person shares with =h& 9090 (native_cutter_sessions_list, native_cutter_command_run; tested against a stand-in server, not yet a real Cutter). Every tool is listed in docs/tools.md.

Known limits

• Locks: every mutex but the browser viewer's goes through platform::sync. A deadlock on one thread or across threads is broken when it forms, with an error and a report in logs/; a watchdog looks every 5 s; a holder that isn't a labelled job is reported after 2 minutes and waited on for 15 at most. Tools are labelled, so they may run as long as they need. Checked by unit tests of each case, not by a live deadlock in the desktop app. Waits on channels and join aren't watched; each child program has its own deadlines.
• A failed agent CLI run says what ran and what it printed, and writes a private log to logs/ in the config folder (the newest 50 are kept; the person's message is left out; Open log in the app, log: in the CLI). Checked live against a GitHub ssh alias from the CLI; the button by a UI test, not by clicking it in the desktop app. API backends and MCP start-up don't write these logs yet.
• Live end-to-end runs (2026-10-18, Windows 10, headless CLI): a website clone reached Ready at 96% likeness in 1.5 min; a small desktop app rebuilt in Rust + egui reached Ready in 9 min (checked only by building); a game rebuild in Rust reached Build and was stopped before Check. The website case is an opt-in test: CRAFT_E2E=1 cargo test -p craft-anything-cli --test live_rebuild.
• Approvals differ by agent (roadmap R2.2): Claude Code asks our approval tool; OpenCode's builder runs with --auto; Hermes's -z turns its approvals off on every run, chats included, so a Hermes chat isn't limited to analysing and Clean room's approval rule doesn't reach it. Hermes is opt-in and hasn't been run live here.
• Claude Code is fully wired as a builder; Codex works through its own flags but is unverified on a real install and doesn't resume; other agent programs get plain text in and out. API-key backends (Anthropic, OpenRouter, OpenAI, local; Kimi K3 through OpenRouter is offered by Detect; a backend chosen as the Extractor takes a Deep-mode game's own files out into app/Original/ after the study) build with our own loop and the Build tools, trim and summarise long conversations and keep them in transcript.json; no live API build has been run yet.
• Website checks compare the start page and up to 12 linked pages at the configured widths; the start page's menus, pop-ups and tabs are opened on the build too and compared in the note (the first few only, never menus inside menus or hover-only ones). Apps and games are checked by building and by a screenshot compared with the person's pictures (and the original's window when runtime study is on; then the build is also started normally, and its window and labelled controls are compared with the original's); games (and apps decompiled in Deep mode) also keep app/mechanics.json, which is checked for being readable and sourced, and fails while a number found in the original isn't used in the code (estimates may stay out). Every game must also pass its own --self-test (the build plays its core loop with scripted input and reports whether the player moved, acted and the HUD was drawn), and a Deep-mode game that uses the original's files must have app/CREDITS.md and the private-use line in app/README.md. The self-test is the build's own report: Craft Anything doesn't yet watch the game play or measure the values itself.
• In Deep mode, app and game targets get a static study (triage, engine detection, file inventory, JS app graph, Ghidra when installed); in Clean room only the person's pictures and words. With runtime study on, the original is also started once for a picture of its window and its UI tree (Windows and macOS); it isn't driven or watched over time.
• Several projects build at once ([build] parallel, 2 by default; Settings → Builds); more wait their turn. Queued builds start on their own as places come free, from MCP too.
• Some flows exist only in the desktop app: the project feed, game-engine and Ghidra installs, and launching results (ROADMAP R1.6).
• Engine gaps from the audit: Frida session tools are partly simulated; imports outside the argument-count table show only the arguments set in the calling block. See tool-status.md.

Next

See ROADMAP.md for the ordered plan.