Operative source account
The names on the pipeline are module responsibilities, not a claim that the public demonstration performs a finished CAD conversion.
ApollonianDesign has a specific declared purpose: to take furniture references from an AutoCAD drawing and prepare a SketchUp scene whose placed models follow the source plan. The operative repository contains both a Windows automation package written for that purpose and a web dashboard written to display its intermediate data. Those two layers are not presently equivalent. The dashboard is useful as a data-contract demonstration and control-surface prototype; the underlying package contains concrete extraction, placement, model retrieval, export, and checking routines; but the current web execution route deliberately substitutes generated sample data for the Windows toolchain.
What the dashboard implements now
The FastAPI process maintains one in-memory pipeline state with a job identifier, an overall status, a current stage, per-stage statuses, an error field, and seven result collections: extracted furniture, layout instructions, model catalogue, assignments, Ruby source, validation results, and placement manifest. A browser connection receives the current snapshot and subsequent events through the WebSocket endpoint. CPU and system-wide memory measurements are sampled through psutil; GPU load is reported when GPUtil can discover a device. The same result collections are also exposed through separate REST read endpoints.
The six visual stages are Analyst, Architect, Executive Producer, Artist, Optimization, and Quality. The ProjectManager exists in the automation package as the coordinator, but it is not a seventh server stage and does not appear as a node in the current dashboard contract. Execute starts a background thread, Kill sets a stop event and waits briefly for that thread, and the browser updates the canvas, tables, log, error panel, status badge, and metrics as messages arrive.
What an execution presently means
The server function is named run_real_pipeline, yet its active branch explicitly invokes run_simulated_pipeline even when the package imports successfully. That simulation emits five fixed furniture records, converts them into layout rows, fabricates three catalogue entries per category, chooses the first entry for each assignment, emits a Ruby script as text, and reports four successful validation records without opening either desktop application. Completing that sequence proves that the dashboard and event protocol can carry each expected kind of result. It does not prove that a DWG was read or an SKP was written.
Opening the HTML directly from disk activates a second, browser-only demonstration with three sample objects. On an HTTP host the browser instead attempts the API and WebSocket routes. These modes should be read as interface demonstrations. Their furniture names, model links, output messages, and passing validation rows are generated examples rather than evidence about a submitted drawing.
The intended Windows automation chain, as represented in operative modules
| Module | Implemented operation | Exact present boundary |
|---|---|---|
| Analyst | Uses Python COM initialization and creates an AutoCAD application, opens the selected DWG, walks ModelSpace, accepts block references, and classifies them from block-name or layer keywords. It records handle, name, category, layer, insertion point, rotation, scale-related dimensions, and an axis-aligned bounding box; coordinates are converted from the configured source unit to metres. | Classification is a fixed keyword table for furniture categories. Entity-level extraction failures are skipped. Attribute text is read by a helper, but the current FurniturePlacement constructor stores an empty attributes dictionary, so those attributes do not reach later stages. |
| Architect | Converts each FurniturePlacement into a PlacementInstruction carrying handle, category, name, XY position, rotation, scale, bounding box, and metadata. It replaces the source Z coordinate with the configured 0.01 metre floor offset. | This is a transform-preservation step, not architectural inference. It does not infer walls, rooms, circulation, clearances, style, or a preferred arrangement from the drawing. |
| Optimization | Deep-copies the placement sequence, computes a width and depth from each bounding box with a 0.5 metre minimum, checks it against earlier axis-aligned footprints, and repeatedly advances the Y coordinate by the object's depth plus 0.1 metres until the overlap test clears. | The routine does not evaluate rotated footprints, room boundaries, doors, accessibility, sight lines, design intent, or global optimality. “Optimization” here means this particular sequential overlap adjustment. |
| Executive Producer | Searches the SketchUp 3D Warehouse endpoints concurrently by category, requests entity detail for a configured number of results, and selects the SKP content with the highest relative-path version. It returns identifiers, titles, download and web addresses, thumbnails, category, provider, and file size when supplied. | The code does not perform aesthetic curation or manufacturer verification. Downstream assignment takes the first candidate returned for the category, or the first generic fallback candidate. |
| Artist | Downloads selected SKP files into a cache, writes the assignments to a placement manifest, generates a SketchUp Ruby startup script, opens a template, loads model definitions, applies translation, rotation, and scale, saves the scene, writes a completion marker, and launches SketchUp with that script. | The step requires a compatible local SketchUp executable and usable model downloads. The Python package checks for an output file and completion marker; the public server does not run this code path. |
| Quality | Holds the source placement snapshot, initial layout, optimized layout, and output path. Its integrity routine checks that required state is present, the SKP exists, the placement manifest is valid JSON, manifest and layout counts agree, layout and blueprint counts agree, and the SketchUp status file exists. | These are existence and count checks. They do not inspect the SKP geometry, compare coordinates object by object, render the scene, or judge whether the result visually matches the plan. |
Where the production chain is not yet connected
The package entry point builds the six operative components and hands them to ProjectManager, whose intended order is extraction, initial layout, model gathering, overlap adjustment, SketchUp construction, and validation. The present QualityController, however, exposes methods named update_blueprint_snapshot, update_layout_plan, update_optimized_layout, and process_render_output. Its collaborators currently call differently named methods such as receive_blueprint_snapshot, receive_layout_plan, receive_optimized_layout, and ingest_render_output. Those hand-offs must be reconciled before the package can complete the declared production sequence.
The web server also displays Artist before Optimization, while ProjectManager optimizes before building the scene. In the simulation, the Optimization stage emits status changes but does not alter the sample layout already assigned by Artist. Thus the visual sequence is an event demonstration, not an exact account of the package's operative order.
Configuration and units require the same candour
The modal stores its three values in browser localStorage and posts them to the server, but the server's apply_config_update function is presently empty. Moreover, the browser submits lower-case field names while the Pydantic configuration model declares upper-case names. A successful “SAVE CONFIG” response therefore does not establish that the Python package, AutoCAD ProgID, or SketchUp executable has changed. The checked-in package itself resolves its working directories and honours the SKETCHUP_EXE and APOLLO_ROOT environment boundaries.
The core Analyst returns AutoCAD rotation as radians and the generated SketchUp transformation consumes that value directly. The dashboard tables append a degree symbol to the number they display, while their simulation records use degree-like values. Until that display contract is normalized, the symbol in the interface should not be treated as evidence of the unit used by a real extracted placement.
Current implementation boundary: the repository contains concrete Windows-bound DWG extraction and SketchUp generation code, but the hosted dashboard presently proves only its own simulated event and presentation path. A real conversion requires the local AutoCAD and SketchUp dependencies, corrected Quality hand-off names, an operative server configuration update, alignment between the displayed and actual stage order, and validation against a genuine generated scene. No payment system, usage billing, grant eligibility determination, or remote CAD execution is implemented here.
Technical questions and project correspondence: traffic@nododesigngroup.com.