forgecad 0.9.13 → 0.9.15

package/dist/docs-raw/platform/observability.md

@@ -1,197 +0,0 @@
-# Observability
-
-ForgeCAD uses a self-hosted observability stack on Hetzner:
-
-- Grafana for dashboards and Explore
-- Prometheus for metrics
-- Loki for logs
-- Alloy for Docker log collection
-- node-exporter and cAdvisor for host and container metrics
-- Uptime Kuma for black-box uptime checks
-
-## Why this setup
-
-We explicitly do **not** use the app admin page as the primary operational surface.
-
-The goals are:
-
-- Tailscale-first private operator workflow
-- real dashboards and query UIs
-- logs and metrics on the same box
-- no paid SaaS requirement
-- minimal public exposure
-
-## Access model
-
-Operator-facing observability ports bind only to the Hetzner host's Tailscale address, defaulting to `100.118.68.93`.
-Reach them directly from any authorized device on the tailnet:
-
-- Grafana: `http://100.118.68.93:3000`
-- Uptime Kuma: `http://100.118.68.93:3001`
-- Prometheus: `http://100.118.68.93:9090`
-- Loki: `http://100.118.68.93:3100`
-- Alloy UI: `http://100.118.68.93:12345`
-
-This keeps the stack private without adding a public reverse proxy or requiring an SSH tunnel for routine access.
-If the host's Tailscale IP changes, set `OBSERVABILITY_TAILSCALE_IP` in `/home/kostard/forgecad-observability/.env` before redeploying.
-The Compose file uses pinned image digests rather than floating `latest` tags so repeat deploys stay predictable.
-
-## Deploy
-
-```bash
-bash scripts/prod/observability-deploy.sh
-```
-
-The deploy script:
-
-1. syncs `ops/observability/` to `/home/kostard/forgecad-observability` on Hetzner
-2. creates `/home/kostard/forgecad-observability/.env` if it does not already exist
-3. pulls fresh images
-4. starts the stack with `docker compose up -d`
-
-## Check status
-
-```bash
-bash scripts/prod/observability-status.sh
-```
-
-## Incident Workflow
-
-This stack is the primary way we debug production incidents.
-
-1. Make sure your laptop is connected to Tailscale.
-
-2. Check Uptime Kuma first:
-
-- `http://100.118.68.93:3001`
-- Use it to answer "is the site/API reachable from outside?" before diving into internals.
-
-3. Check Grafana next:
-
-- `http://100.118.68.93:3000`
-- Start with the `ForgeCAD Host Overview` dashboard.
-- Then switch to `ForgeCAD Web Requests` for throughput, 4xx/5xx rate, latency, and top API routes.
-- Then switch to `Explore` for live investigation.
-
-4. In Grafana Explore, use:
-
-- `Loki` when you want logs
-- `Prometheus` when you want metrics
-
-Useful Loki queries:
-
-```text
-{container=~"forgecad-web-.*|forgecad-backend-web-.*"}
-{container=~"forgecad-web-.*|forgecad-backend-web-.*"} |= "error"
-{container=~"forgecad-web-.*|forgecad-beta-web-.*"} |= "DB slow query"
-{container=~"forgecad-web-.*|forgecad-beta-web-.*"} | json | event="db.query"
-{container=~"forgecad-beta-.*"}
-{container="kamal-proxy"}
-```
-
-Useful Prometheus queries:
-
-```text
-up
-node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes
-100 * (1 - node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{mountpoint="/",fstype!~"tmpfs|overlay"})
-sum by (container) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))
-sum(rate(forge_http_request_total[$__rate_interval]))
-sum(rate(forge_http_request_total{surface="api",status_class="5xx"}[$__rate_interval]))
-histogram_quantile(0.95, sum by (le) (rate(forge_http_request_duration_seconds_bucket[$__rate_interval])))
-topk(10, sum by (forge_env, method, route) (rate(forge_http_request_total{surface="api"}[$__rate_interval])))
-sum by (forge_env, operation) (rate(forge_db_query_total[$__rate_interval]))
-histogram_quantile(0.95, sum by (forge_env, operation, le) (rate(forge_db_query_duration_seconds_bucket[$__rate_interval])))
-sum by (forge_env, relation) (rate(forge_db_slow_query_total[$__rate_interval]))
-```
-
-5. Use the `ForgeCAD Web Requests` dashboard when the issue smells app-level traffic, request failures, or latency:
-
-- overall request rate
-- API-only request rate
-- 4xx and 5xx rates
-- P95 request latency
-- request concurrency
-- top API routes by throughput, 4xx rate, 5xx rate, and latency
-
-Health probes to `/api/health` are intentionally excluded so low-traffic charts stay focused on real user traffic instead of uptime polling.
-
-6. Use the `ForgeCAD DB Queries` dashboard when the issue smells database-related:
-
-- Query rate by operation
-- P95 query latency by operation
-- Slow-query rate
-- Error-query rate
-- Top relations by average latency
-- Queries currently in flight
-
-The dashboard is backed by app-native metrics from the ForgeCAD web service, not host-level guesses.
-
-6. Re-check prod explicitly after any restart or deploy:
-
-```bash
-curl -fsS https://forgecad.io/api/health
-```
-
-7. If observability itself is degraded, fall back to SSH and direct Docker inspection:
-
-```bash
-ssh hetzner
-docker ps --format "{{.Names}}\t{{.Status}}"
-docker logs --tail 200 <container>
-df -h /
-free -h
-```
-
-## Tool Roles
-
-- `Grafana`: main operator UI for dashboards, Explore, and datasource-backed queries
-- `Loki`: log backend queried through Grafana Explore
-- `Prometheus`: metrics backend and alert rule evaluation
-- `Uptime Kuma`: external uptime/status checks
-
-## Credentials
-
-Grafana admin credentials live on Hetzner in `/home/kostard/forgecad-observability/.env`.
-
-## What phase 1 covers
-
-- host CPU, memory, and disk metrics
-- container CPU and memory metrics
-- Docker stdout/stderr logs in Loki
-- app-native HTTP request metrics from the ForgeCAD web app
-- app-native DB query metrics from the ForgeCAD web app
-- Grafana data sources and a starter host dashboard
-- a provisioned `ForgeCAD Web Requests` dashboard
-- a provisioned `ForgeCAD DB Queries` dashboard
-- starter Prometheus alert rules for target health, memory, disk, and observability restarts
-- Uptime Kuma for health checks and notifications
-
-Prometheus reaches the web app metrics listener over the private `kamal` Docker network. The app exposes `/metrics` on an internal metrics port, not through the public Cloudflare route.
-
-## What phase 1 does not cover
-
-- distributed Loki storage
-- Postgres-native query stats such as `pg_stat_statements`
-- tracing / Tempo
-- public Grafana hostnames
-- automatic provisioning of Uptime Kuma monitors
-
-Those can be added later once the basic operator loop is working.
-
-## First Alerts
-
-Phase 1 ships starter Prometheus rules for:
-
-- observability targets going down
-- host memory staying below 10% available
-- root disk staying below 15% free
-- observability containers restarting
-
-These are intentionally conservative. Let them bake before wiring noisy notifications.
-
-## Rollback and Safety
-
-- Stop the stack with `cd /home/kostard/forgecad-observability && docker compose down` if it causes unexpected pressure.
-- The observability services bind only to the host's Tailscale address, so they stay off the public internet and do not compete with Kamal for `80/443`.
-- Prod health should always be rechecked with `curl -fsS https://forgecad.io/api/health` after any observability deploy or restart.

package/dist/docs-raw/platform/projects.md

@@ -1,111 +0,0 @@
-# Projects and File Management
-
-Projects are the top-level container for user work in ForgeCAD. Each project groups related scripts and output files under a single name with access controls.
-
-## Project Model
-
-Each project has:
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `id` | UUID | Primary key |
-| `slug` | string | URL-safe identifier, unique per owner |
-| `name` | string | Display name |
-| `visibility` | `private` \| `public` | Controls unauthenticated access |
-| `ownerId` | UUID | Foreign key to the user who created the project |
-
-Source: `server/db/schema.ts`
-
-## Member Roles
-
-Projects support collaborative access through membership:
-
-| Role | Capabilities |
-|------|-------------|
-| **owner** | Full control: rename, delete, manage members, read/write files |
-| **editor** | Read and write files (save, delete, mkdir) |
-| **viewer** | Read files, watch for changes |
-
-The owner is always the user who created the project. Ownership cannot be transferred through the membership API.
-
-## File Storage
-
-Project files are stored on disk, not in the database. The storage root is configured by the `FORGE_STORAGE_ROOT` environment variable (default: `/data/projects` in Docker). Each project gets an isolated directory under this root.
-
-See [deployment.md](../deployment.md) for Docker volume and storage configuration.
-
-### Supported File Types
-
-| Extension | Purpose |
-|-----------|---------|
-| `.forge.js` | ForgeCAD model scripts |
-| `.js` | Utility modules (imported by scripts) |
-| `.svg` | Vector assets |
-| `.dxf` | 2D CAD profile assets |
-| `.stl`, `.3mf` | Exported mesh files |
-
-### Path Traversal Protection
-
-All file operations validate resolved paths against the project's storage directory. Any path that escapes the project root (via `..` segments or symlinks) is rejected. This check runs in `server/storage.ts` before any read or write reaches the filesystem.
-
-### Storage Quotas
-
-Each user has a storage quota tracked via `storage_used_bytes` on the user record.
-
-| Limit | Value |
-|-------|-------|
-| Storage per user | 50 MB |
-| Projects per user | 20 |
-
-The quota is checked before every file write. Storage counters are adjusted atomically and clamped to zero to prevent negative drift from race conditions or deleted files.
-
-Source: `server/quotas.ts`
-
-## Real-Time File Watching
-
-Clients can subscribe to file changes via Server-Sent Events:
-
-```
-GET /api/projects/:id/watch
-```
-
-This endpoint streams events whenever files in the project are created, modified, or deleted. The editor uses this to stay in sync when multiple clients have the same project open.
-
-## API Endpoints
-
-### Projects
-
-| Method | Route | Min Role | Purpose |
-|--------|-------|----------|---------|
-| GET | `/api/projects` | -- | List the authenticated user's projects |
-| POST | `/api/projects` | -- | Create a new project |
-| GET | `/api/projects/:id` | viewer | Get project details |
-| PATCH | `/api/projects/:id` | owner | Update project name, slug, or visibility |
-| DELETE | `/api/projects/:id` | owner | Delete project and all its files |
-
-### Members
-
-| Method | Route | Min Role | Purpose |
-|--------|-------|----------|---------|
-| GET | `/api/projects/:id/members` | viewer | List project members |
-| POST | `/api/projects/:id/members` | owner | Add a member by user ID |
-| PATCH | `/api/projects/:id/members/:userId` | owner | Change a member's role |
-| DELETE | `/api/projects/:id/members/:userId` | owner | Remove a member |
-
-### Files
-
-| Method | Route | Min Role | Purpose |
-|--------|-------|----------|---------|
-| GET | `/api/projects/:id/watch` | viewer | SSE stream of file changes |
-| POST | `/api/projects/:id/save` | editor | Write file contents to disk |
-| POST | `/api/projects/:id/delete` | editor | Delete a file |
-| POST | `/api/projects/:id/mkdir` | editor | Create a directory |
-| GET | `/api/projects/:id/read-binary` | viewer | Download a binary file (meshes, assets) |
-
-Source: `server/routes/projects.ts`, `server/routes/files.ts`
-
-## Related
-
-- [Architecture](architecture.md) -- system overview and deployment topology
-- [Sharing](sharing.md) -- model publishing and public URLs
-- [Deployment](../deployment.md) -- storage volume configuration, Docker setup

package/dist/docs-raw/platform/sharing.md

@@ -1,90 +0,0 @@
-# Model Sharing and Publishing
-
-ForgeCAD supports multiple ways to share models. Two categories exist: **server-backed publishing** (persistent URLs, requires auth to publish) and **client-side sharing** (no server needed, data encoded in the URL).
-
-See [architecture.md](architecture.md) for the full URL route table.
-
-## Server-backed publishing
-
-Authenticated users can publish models to get a stable, public URL. Published models are stored in the `shared_files` database table.
-
-### Database schema (`shared_files`)
-
-| Column | Type | Notes |
-|--------|------|-------|
-| `id` | uuid | Primary key |
-| `share_id` | text | Unique, 10-char nanoid -- the URL identifier |
-| `owner_id` | uuid | FK to `users.id`, cascade delete |
-| `filename` | text | Original filename |
-| `code` | text | Full source code |
-| `title` | text | Optional display title |
-| `created_at` | timestamptz | Auto-set |
-| `updated_at` | timestamptz | Auto-set, updated on re-publish |
-
-### Public URLs
-
-| URL | Behavior |
-|-----|----------|
-| `/m/:shareId` | Full model preview: source code panel + 3D viewport |
-| `/m/:shareId?embed=1` | Viewport only, no UI chrome -- designed for iframe embeds |
-
-No authentication is required to view a published model.
-
-### API endpoints
-
-| Method | Route | Auth | Purpose |
-|--------|-------|------|---------|
-| GET | `/api/shares/:shareId` | None | Fetch a published model (code, title, author name, timestamps) |
-| GET | `/api/shares` | Required | List the authenticated user's published models |
-| POST | `/api/shares` | Required | Publish a new model or update an existing one |
-| DELETE | `/api/shares/:shareId` | Required (owner or admin) | Unpublish a model |
-
-### Publish behavior
-
-- If the user already has a published model with the same filename, `POST /api/shares` updates the existing share rather than creating a new one. The `share_id` is preserved so existing links remain valid.
-- Each user may publish up to **100** models. Exceeding this limit returns `403` with `{ error: "Share limit reached" }`.
-- All publish, update, and delete operations are recorded in the `audit_log` table.
-
-### Audit trail
-
-Every share mutation writes to `audit_log` with one of these actions:
-- `share.publish` -- new model published
-- `share.update` -- existing model code/title updated
-- `share.delete` -- model unpublished
-
-## Client-side sharing (no server)
-
-These methods encode model data directly into the URL. They work without authentication and without the hosted backend.
-
-### Inline code (hash fragment)
-
-Format: `/app#code/<filename>/<lz-compressed-code>`
-
-The code is compressed with `lz-string` (`compressToEncodedURIComponent`) and placed in the URL hash. Since hash fragments are not sent to the server, this works entirely client-side. Encoding and decoding logic lives in `src/share.ts`.
-
-### Multi-file bundles (hash fragment)
-
-Format: `/app#bundle/<lz-compressed-packed>`
-
-Packs multiple files into a single compressed payload using null-byte separators: `entry\0filename1\0code1\0filename2\0code2...`. Used when a model has import dependencies.
-
-### Gist sharing
-
-Format: `/app?gist=<github-gist-id>`
-
-Fetches code from a public GitHub Gist at load time.
-
-### URL sharing
-
-Format: `/app?url=<external-url>`
-
-Fetches code from any publicly accessible URL at load time.
-
-## Source files
-
-| File | Role |
-|------|------|
-| `server/routes/shares.ts` | API route handlers for publish/unpublish/list |
-| `server/db/schema.ts` | `sharedFiles` table definition and types |
-| `src/pages/SharedModelPage.tsx` | Frontend page rendering `/m/:shareId` |
-| `src/share.ts` | Client-side encode/decode for hash-based sharing |

package/dist/docs-raw/product/README.md

@@ -1,39 +0,0 @@
-# Product Docs
-
-These docs are product-first. They are for PMs, founders, designers, product engineers, and strategic reviewers who need to decide what ForgeCAD should become.
-
-They intentionally overlap with developer docs in a few places, but they have a different job. Product docs explain the market, user, workflow, and business reason behind a direction. Developer docs explain how to implement it safely.
-
-Use the generated API docs and ForgeCAD skills for exact API usage. Use this folder to decide which API vocabulary, workflow, customer segment, or manufacturing route deserves attention.
-
-## Themes
-
-| Theme | Read this when the question is |
-|---|---|
-| [Vision](vision.md) | What is ForgeCAD, really? |
-| [Founder Story](founder-story.md) | Why did this product start, and what problem did it reveal? |
-| [API As Product Language](api-as-product-language.md) | Why does API vocabulary matter as product strategy? |
-| [Product Loop](product-loop.md) | What loop makes AI-authored CAD reliable? |
-| [User Segments](user-segments.md) | Who are we building for first, next, and later? |
-| [Creative Manufacturing](creative-manufacturing.md) | What is the first wedge? |
-| [Manufacturing Workflows](manufacturing-workflows.md) | How should we think about 3D printing, laser cutting, CNC, furniture, robotics, and export routes? |
-| [Competitive Positioning](competitive-positioning.md) | How should ForgeCAD be compared to OpenSCAD, CadQuery, Fusion, Onshape, Zoo, and prompt-to-CAD tools? |
-| [Business Model](business-model.md) | Where can early revenue come from? |
-| [Strategic Decisions](strategic-decisions.md) | How should future product bets be judged? |
-
-## Tactical Product Docs
-
-These docs are narrower product operating notes:
-
-- [First Account Onboarding](onboarding-first-experience.md) - source of truth for new-account first-run behavior.
-- [User Outreach Email Templates](user-outreach-email-templates.md) - founder-style user discovery and onboarding outreach.
-
-Theme docs should stay short and easy to scan. Tactical docs may be longer when they contain templates, checklists, or implementation maps, but they should still link back here so the product reading path stays clear.
-
-## How To Use This Folder
-
-Start with [Vision](vision.md), [Product Loop](product-loop.md), and [Creative Manufacturing](creative-manufacturing.md) if you are new to the product.
-
-Read [Manufacturing Workflows](manufacturing-workflows.md) before deciding whether to add a manufacturing feature such as CNC primitives, slicer integration, sheet workflows, or furniture cut lists.
-
-Read [Strategic Decisions](strategic-decisions.md) when a feature sounds exciting but the product reason is still fuzzy.

package/dist/docs-raw/product/api-as-product-language.md

@@ -1,13 +0,0 @@
-# API As Product Language
-
-In ForgeCAD, the API is not only a developer convenience. It is the product language that AI agents use to express physical intent.
-
-This is why API design is a product decision. When the API has a first-class concept like a connector, gear, sheet bend, inspection bundle, or manufacturing export, the agent can discover it in docs, compose it, validate it, and explain it to the user. When the API lacks that concept, the agent improvises with lower-level geometry and the product becomes fragile.
-
-ForgeCAD skills should teach the API that exists. Product docs should help decide which vocabulary deserves to exist next. Those are different jobs. The skills can say how to use a function; product docs should say why that family of functions matters to users, markets, workflows, and business strategy.
-
-The best API additions reduce how much specialist knowledge the agent must recreate from scratch. A strong agent can learn a lot from documentation, but documentation should not become a substitute for a domain-shaped product surface. If three agents would implement three fragile versions of the same common manufacturing idea, ForgeCAD likely needs a real concept for it.
-
-Product managers should look for repeated recipes, repeated user friction, repeated validation failures, and repeated market requests. Those are signals that the product vocabulary is too weak. The answer may be a new API, a better workflow, a diagnostic, a starter template, a partner integration, or a higher-level export path.
-
-The product goal is not the largest possible API. The goal is a vocabulary that makes common physical design intent obvious, inspectable, and manufacturable.

package/dist/docs-raw/product/business-model.md

@@ -1,15 +0,0 @@
-# Business Model
-
-ForgeCAD has three early business paths. They should be explored deliberately instead of blended into one vague market.
-
-The first path is Pro users in creative manufacturing. These are makers, engineers, designers, educators, and small teams who want stronger AI-assisted modeling, exports, private projects, and validation workflows. This path proves repeat usage and product-led demand.
-
-The second path is embedded parametric commerce. Furniture companies, custom product stores, marketplaces, and printer ecosystems can use ForgeCAD underneath a guided customization experience. The buyer is not paying for "CAD." They are paying for safer customization, fewer manual design steps, better visuals, manufacturing logic, and a shorter path from user intent to orderable object.
-
-The third path is strategic enterprise or AI-CAD pilots. These customers care about agent evaluation, semantic CAD generation, backend routing, data, export reliability, or integration into existing workflows. This path can create revenue and strategic signal, but it can also pull the product toward custom services too early.
-
-The product should separate model authoring value from hosted workflow value. A partner may pay for a parametric product family, an embed, hosting, support, usage, or an integration. Those are different products, even if they share the same engine.
-
-For early business judgement, the strongest evidence is not a broad market slide. The strongest evidence is a repeated paid job: users or partners ask ForgeCAD to generate useful physical objects, the loop succeeds, the output is trusted, and the customer returns.
-
-Pricing and deal numbers belong in private planning docs when they include negotiation anchors. The permanent product docs should preserve the strategic shape: Pro subscriptions, partner integrations, OEM/marketplace pilots, and enterprise AI-CAD workflows.

package/dist/docs-raw/product/competitive-positioning.md

@@ -1,17 +0,0 @@
-# Competitive Positioning
-
-ForgeCAD should not be positioned as "OpenSCAD but newer" or "a JavaScript clone of existing CAD-as-code." That framing makes the product sound like a library choice. The stronger framing is that ForgeCAD is an AI-native workflow for editable, manufacturable physical design.
-
-OpenSCAD proved that code can be a CAD interface for programmers. CadQuery and build123d show that Python can express serious parametric CAD with an exact kernel. Replicad shows that browser and JavaScript CAD can be elegant. These tools are valuable, but they are mainly library or authoring environments.
-
-Fusion, Onshape, and SolidWorks are professional CAD systems. They are powerful because they serve trained users, teams, manufacturing workflows, and enterprise expectations. They are not naturally shaped around autonomous agents editing semantic source, running validation, producing inspection evidence, and routing outputs from a project folder.
-
-Prompt-to-CAD tools are close to the user's desire: describe an object and get geometry. The risk is that the result becomes a dead artifact. ForgeCAD should win by keeping the model editable, parameterized, validated, and exportable after generation.
-
-Zoo and KCL are closer to the same future because they also connect code, AI, and CAD. ForgeCAD's strongest differentiation should be backend-agnostic intent, JavaScript/TypeScript familiarity, local-agent workflow, validation evidence, project sync, and an early focus on daily creative manufacturing rather than only professional CAD replacement.
-
-The one-line positioning:
-
-**OpenSCAD made code a CAD interface for programmers. Fusion and Onshape made CAD collaborative for professionals. ForgeCAD makes editable physical design accessible to AI agents and daily users.**
-
-Product work should reinforce that sentence. If a feature only makes ForgeCAD look like a smaller traditional CAD tool, it needs a sharper reason to exist.

package/dist/docs-raw/product/creative-manufacturing.md

@@ -1,15 +0,0 @@
-# Creative Manufacturing
-
-Creative manufacturing is the first product wedge.
-
-The user has a real-world problem and access to a way to make things: a 3D printer, laser cutter, CNC service, local workshop, online manufacturing service, or a partner marketplace. They do not want to spend weeks learning traditional CAD. They want to turn everyday intent into a usable object.
-
-The objects are practical and personal: drawer organizers, brackets, adapters, cable guides, kitchen and bathroom helpers, electronics enclosures, fixtures, toys, lamps, furniture fittings, small mechanisms, replacement parts, and custom mounts.
-
-This wedge is different from professional CAD replacement. ForgeCAD does not need to beat Fusion, Onshape, or SolidWorks on every enterprise workflow to be useful. It needs to make the first useful object dramatically easier for people who are currently blocked by CAD expertise.
-
-The wedge is also different from pure prompt-to-mesh. The result should remain editable. If the adapter is 2 mm too short, the user should change a parameter or ask the agent to adjust the model, then validate and export again. If the furniture fitting needs a different screw pattern, the model should carry enough intent to change safely.
-
-The product should favor workflows where repeated small wins compound. A user who makes one useful object can make another. A printer company that helps users make useful objects sells more printer value. A furniture site that lets customers safely customize dimensions reduces friction around fit.
-
-Creative manufacturing is not a small niche if the loop becomes reliable. It is the habit of solving physical problems with generated, editable, manufacturable objects.

package/dist/docs-raw/product/founder-story.md

@@ -1,11 +0,0 @@
-# Founder Story
-
-ForgeCAD started from a long-running curiosity about AI interfaces: what does the AI see, what language does it act through, and how much better does it become when the interface is engineered for it?
-
-That question became practical during a physical design problem. Ruben wanted to make a custom loft table and realized that a closed CAD system was a poor surface for AI help. If the object lives only inside a complex GUI or proprietary binary state, the AI cannot reliably inspect it, change it, run it, and learn from errors.
-
-Code was not chosen because code is magical. Code was chosen because it is both machine-operable and human-readable. The deeper requirement is an expressive representation that AI can learn, humans can inspect, and tools can validate. ForgeCAD uses code as that representation today because it gives parameters, composition, reviewability, and a natural path for agent workflows.
-
-The early browser-first implementation used Manifold and Three.js because fast iteration mattered. A user or agent could change the model and see something quickly. Over time, the product grew beyond browser preview into multiple backends, exact export exploration, hosted projects, sharing, skills, inspection bundles, and manufacturing outputs.
-
-The important origin lesson is not "build a CAD-as-code tool." The lesson is "design the interface AI needs in order to make physical objects responsibly." ForgeCAD exists because the AI age changes who does the modeling work and therefore changes what the CAD interface should be.

package/dist/docs-raw/product/manufacturing-workflows.md

@@ -1,15 +0,0 @@
-# Manufacturing Workflows
-
-Manufacturing workflows should be evaluated as product routes, not only as geometry features.
-
-3D printing is the easiest first route because STL/3MF outputs are familiar, iteration is local, and users tolerate prototypes. The product value is not only export. It is parameter checks, wall-thickness evidence, connectivity checks, print-oriented templates, and the ability for an agent to repair the model after feedback.
-
-Laser cutting and sheet workflows are natural next routes because they turn design intent into flat parts, joints, labels, nesting, and assembly guidance. The product question is whether ForgeCAD can reduce the user's need to manually plan tabs, kerf, slots, bend reliefs, and cut sheets.
-
-CNC should be treated carefully. "Add CNC primitives" should not mean adding random geometry helpers named after machining words. The user need is closer to stock, workholding, material, tool access, pockets, contours, drilling, dogbones, tabs, tolerances, and safe output routing. A PM should ask whether the feature helps the AI express manufacturable machining intent and whether ForgeCAD can validate enough of that intent to be trusted.
-
-Furniture and custom product workflows are especially business-relevant. A customer does not want a CAD editor inside a furniture store. They want safe customization, dimensions, visuals, price logic, BOM/cut-list logic, and an orderable product. ForgeCAD can be the parametric engine underneath that experience.
-
-Robotics and mechanism workflows matter because they show ForgeCAD is not just static shapes. Connectors, joints, collision checks, exports, and kinematic evidence can make the product valuable for users who need motion and system-level relationships.
-
-The decision rule is simple: a manufacturing workflow is strong when it connects user intent to a validated output route. If ForgeCAD cannot validate or constrain the route yet, the feature may still be worth exploring, but it should be framed as discovery rather than production promise.