Release planning

CadCraft 0.9 impact map

Every fix and feature lined up for 0.9, and what each one touches: which apps, and which layers of the stack.

ProjectCadCraft
Sheet0.9 impact
Items273
Date2026-11-09
115Fix
147Feature
4Spike
0Platform
0Site ops
0Sanity check
7Decision
≈ 0days in the written 0.9 plans
  • Planned 0 on the plan for the release it is filed under
  • Built 271 built and working in /lab (the dev builds). Whether the public has it is its reach: "in the lab", "Live" (the last gate) or "switched off"; see docs/REACH-LIVE.md
  • Partly built 1 part of it is built in /lab; the rest waits (see "Waits on")
  • Promised 0 the live site already says it is coming
  • Moved 0 moved here from an earlier release or wishlist
  • Found 0 bug found after a release shipped; fixed in a point release or the next one
  • Candidate 0 recommended in a spike or session log; owner to choose
  • Community please test 0 built and in /use; a Discord post gives the steps and the expected result and asks people to try it on their own devices, files or know-how
  • Decision Time 0 a decision, check, file, key, flag or go only you can give; folds into the list once answered

Built means built and working in the lab. Live means the public can use it, and is the last gate: 270 Built · Live, 1 Built · in the lab.

Sheet 1 · impact areas

Where 0.9 lands

How many items touch each app and each layer, by kind. One item can touch several areas, so the rows add up to more than the item count. Pick a row to filter the schedule below.

Impact areaFixFeatureSpikePlatformSite opsSanity checkDecisionAll
Apps
CadCraft 38 36 – – – – 2 76
BimCraft 27 53 2 – – – – 82
ModelCraft 19 45 2 – – – 2 68
MarkupCraft 16 11 – – – – – 27
TakeoffCraft 18 7 – – – – – 25
CivilCraft 14 32 – – – – – 46
DetailCraft 13 13 – – – – – 26
PartCraft 18 27 1 – – – – 46
Studio 2 5 1 – – – – 8
SuperCad Studio 22 17 – – – – – 39
Layers
Site and services 7 11 – – – – 5 23
Desktop host 1 1 1 – – – – 3
App shell 2 1 – – – – – 3
App code 10 28 3 – – – 3 44
Our engines – 12 1 – – – 1 14
Vendor engines – – – – – – – 0
Drawing surface – – – – – – – 0
Help and words 1 2 – – – – 1 4
Tests and tooling – – – – – – – 0

Sheet 2 · schedule

Every fix and feature

Grouped by track. App chips carry each app’s layer colour; Studio is in ink. "Waits on" names what has to happen first; the small lines under it say who asked and where the item is written up.

Add an item Fork map (Rust and C++ forks) The roadmap

Issues sync every 10 minutes; last sync Nov 9, 2026 6:40 pm.

ItemWhatAppsLayersStatusDaysWaits onIssues
From GitHub (to review) 2
FeatureBot obtainedGH.5 Link to GH.5Comment on GH.5 DWG reader: class list fails when a class's maintenance version is 256 or more (read as BITSHORT, spec has BITLONG)

## Summary `readClassesSection` in `app/dwg/read.js` (line 229) reads each R2004+ class record's DWG version and maintenance version as BITSHORT. The Open Design Specification for .dwg files v5.4.1, chapter 10, gives both as BITLONG. The two encodings agree for values 0 to 255 and part from 256 up: BITSHORT code 00 is followed by 16 bits and BITLONG code 00 by 32, and BITSHORT code 11 means 256 where BITLONG has no code 11. So a class whose maintenance version is 256 or more shifts every later field by 16 bits, and the read stops with `Classes could not be read: bad BITLONG code 11`. ## Where we saw it Three real R2018 (AC1032) drawings from a third party (we cannot share the files). Their class records carry DWG version 33 with maintenance version 329 for MLEADERSTYLE, ACDBDETAILVIEWSTYLE and SUN. The classes before the first of those (ACDBDICTIONARYWDFLT, MATERIAL, VISUALSTYLE, SCALE, TABLESTYLE) read fine, so the read fails on the class right after MLEADERSTYLE. A fourth R2018 drawing whose classes are all below 256 reads correctly. ## Effect - `model.classes` comes back empty, with the note `Classes could not be read: bad BITLONG code 11`. - Every class-based object then reads as unknown (`CLASS_5xx` in `report.unknown`). In our files that included two IMAGE entities inside a title block definition, which dropped out of the drawing. - `writeDwg(readDwg(bytes), { version: 'AC1032' })` leaves those objects out: "Not copied (cc-dwg cannot write them in this version, or they depend on them): 3 CLASS_501, 24 CLASS_502, 17 CLASS_503, 1 CLASS_504, 1 CLASS_505, 1 CLASS_506, 1 CLASS_507, 1 CLASS_508, 2 CLASS_511, 2 CLASS_512, 1 CLASS_513, 5 CLASS_509." Model space, layer… Opened on GitHub by a Discord member: https://github.com/getcadcraft/cadcraft/issues/5 Sweep 2026-11-05: accepted into 0.9 (planned). cad-fix-09 2026-11-05 (done): see docs/0.9-sessions/cad-fix-09.md.

CadCraft Built · Live – – From: a Discord member (GitHub) GitHub getcadcraft/cadcraft#5, Oct 28, 2026 cadcraft#5 open
FeatureBot obtainedGH.10 Link to GH.10Comment on GH.10 Assistant/MCP: tools to place electrical devices (sockets, switches, lights, …)

### What do you need to do Let an AI assistant place electrical devices (sockets, switches, luminaires, detectors, boards, …) through the MCP / assistant interface, the same way it can already draw walls, openings, floors and cable carriers. Today the assistant tool set has no way to create a device: - `carrier_add` draws cable trays and conduits, and `carriers_check` / `lighting_check` / `loads_set` / `photometry_set` work on what is there, - but none of the ~80 tools (`agents.js`, `mep-agents.js`, `bim-agent.js`, …) places a device. `furniture_add` only furnishes rooms by rule. So an assistant can route conduits to an outlet it cannot create, and an electrical plan still has to be clicked in by hand. The building blocks already exist in `app/res-elec.js` (`placeDevice`, `changeDevice`, `linkLight`, `removeDevices`, `DEVICES` with 33 kinds). Exposing them as tools would cover it, for example: | Tool | Does | Arguments (sketch) | |---|---|---| | `devices_add` | Place one or more devices | `level`, `kind` (a key of `DEVICES`), `at` [x, y] mm, optional `wall` (snap to the nearest wall face like the UI does), `height`, `angle`, `circuit`, `load_w`, `tag` | | `device_change` | Change tag, circuit, load, height, position | `guid` + fields | | `lights_link` | Link a switch / sensor to the lights it controls | `switch`, `lights[]` | | `devices_delete` | Remove devices (and unlink lights) | `guids[]` | | `devices_list` | Devices of a level with kind, tag, circuit, load, height, host wall, linked lights | `level` | Typical requests this would enable: - "Put a double socket every 2 m along the walls of the living room on level 1, 300 mm high, circuit 3." - "Add a ceiling li… Opened on GitHub by a Discord member: https://github.com/getcadcraft/bimcraft/issues/16 Sweep 2026-11-05: accepted into 0.9. Assistants/MCP tools to place electrical devices; belongs with the add-on's device kinds (ELEC-BUILDING). bim-hosts-09 2026-11-06 (done): see docs/0.9-sessions/bim-hosts-09.md.

BimCraft Built · Live – Hand check is community test GH.10-HAND (not blocking) From: a Discord member (GitHub) GitHub getcadcraft/bimcraft#16, Nov 3, 2026 bimcraft#16 open
BIM interop 1
FeatureGH.3-A Link to GH.3-AComment on GH.3-A One display unit everywhere

Audit and fix the display-unit pick so coordinates, measurements, sections and sheet scale families all follow it (feet-inches, decimal feet, inches, millimetres, centimetres, metres). Imported DWG coordinates keep their native units where their meaning must stay. Part of GH.3 (GitHub getcadcraft/bimcraft#3). Owner approved 2026-10-29; scheduled for 0.9.

BimCraft Built · Live 2 Requester asked to test 2026-11-03 (bimcraft#3); lab pass once he sends his account email From: yisraelk (GitHub) GitHub getcadcraft/bimcraft#3, Oct 22, 2026
Suggest an item

Anyone can send one; no account and no name needed. The team reads each idea, and the ones we take on appear on this page. Please leave out web addresses.