forgecad 0.9.14 → 0.9.16

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.

package/dist/docs-raw/product/onboarding-first-experience.md

@@ -1,256 +0,0 @@
-# First Account Onboarding Experience
-
-This is a tactical product doc. For the product-first theme map, start with [Product Docs](README.md).
-
-This is the source of truth for the first experience after a person creates a ForgeCAD account.
-
-Any code, docs copy, starter files, CLI guidance, analytics, or launch issue that changes first-run behavior should start by updating this document. The goal is to keep the experience coherent instead of letting it drift across auth, project creation, examples, docs, and CLI surfaces.
-
-## Summary
-
-The first account experience should not drop a new user into an empty editor. A new user should land in a small "Start Here" project with three curated files, a visible docs Welcome page, and a clear path from browser exploration to CLI-based local work.
-
-The recommended first-run path is:
-
-1. Account is created.
-2. User opens `/app`.
-3. If the account has no projects, ForgeCAD creates a private `Start Here` project from the starter template.
-4. The editor opens `00-start-here.forge.js`.
-5. The file itself teaches the first model loop: edit one parameter, run, see geometry change.
-6. The docs nav exposes `/docs/welcome` as the public orientation page.
-7. The Welcome page points to the CLI loop and API docs without making the user read the whole docs set first.
-
-## Decision
-
-Use a curated starter project as the first account artifact. Do not open the full examples project by default for hosted accounts.
-
-The full examples project is too large for first contact. It is useful once the person already knows what kind of thing they are looking for. A first account needs something smaller: one runnable file, one slightly richer parametric file, and one assembly file.
-
-## User Profiles
-
-### Alex - AI-First Maker
-
-**Background:** Uses Codex or Claude Code daily, knows JavaScript well enough to edit generated code, owns a 3D printer.
-
-**What Alex Wants:**
-
-- Get from idea to printable geometry quickly.
-- Ask an AI agent to change a model and validate it through the CLI.
-- Understand which files matter without reading a large reference.
-- Export STL or images from the terminal.
-
-**Ideal Flow:**
-
-```bash
-npm install -g forgecad
-forgecad login
-forgecad project clone start-here
-cd start-here
-forgecad run 00-start-here.forge.js
-forgecad studio .
-```
-
-For GitHub/Google accounts, `forgecad login` should offer API-token login because there is no CLI password to submit.
-
-**Current Friction:**
-
-- A new account sees a blank or near-empty editor state.
-- The CLI is not part of the first-run path.
-- The AI skill exists but is not connected to the account onboarding story.
-
-### Maya - Mechanical Designer Trying Code-CAD
-
-**Background:** Comfortable with CAD concepts, not necessarily with code-first modeling. May use Onshape, Fusion, or SolidWorks.
-
-**What Maya Wants:**
-
-- See a real parametric model immediately.
-- Discover that sliders are parameters, not magic UI state.
-- Find the coordinate system and modeling conventions when she needs them.
-- Avoid feeling that she must read API docs before doing anything.
-
-**Ideal Flow:**
-
-```text
-Sign up -> Start Here project opens -> Width slider is visible -> change it -> model updates -> open Welcome docs for "what next?"
-```
-
-**Current Friction:**
-
-- The editor has powerful panels, but the first screen does not explain the working loop.
-- The file list does not provide a progression.
-- API docs are reference-first rather than first-session-first.
-
-### Sam - Software Engineer Evaluating ForgeCAD
-
-**Background:** Strong TypeScript/JavaScript developer, maybe less CAD knowledge. Wants to know if ForgeCAD fits automation and CI.
-
-**What Sam Wants:**
-
-- Confirm files are plain `.forge.js`.
-- Learn the local workflow and sync model.
-- Know how web projects relate to CLI projects.
-- See commands that can be pasted into a terminal.
-
-**Ideal Flow:**
-
-```bash
-forgecad project clone start-here
-forgecad run 01-parametric-bracket.forge.js
-forgecad render 3d 01-parametric-bracket.forge.js
-forgecad project push
-```
-
-**Current Friction:**
-
-- Hosted app and CLI feel like separate products.
-- GitHub/Google accounts need API tokens for CLI login, but that reason is not in the first-run path.
-- Project clone/push/pull is documented, but not introduced at the moment of motivation.
-
-### Priya - Robotics / Assembly Explorer
-
-**Background:** Interested in mechanisms, robotics, SDF/URDF, and multi-part assemblies. She needs a signal that ForgeCAD is more than boxes.
-
-**What Priya Wants:**
-
-- See multiple files or at least multiple model styles quickly.
-- Discover assemblies, joints/connectors, and exports.
-- Understand where the larger examples live without being dropped into all of them.
-
-**Ideal Flow:**
-
-```text
-Open Start Here -> inspect assembly starter -> follow docs to Assembly -> later browse examples/mechanical
-```
-
-**Current Friction:**
-
-- The first account project does not show the product's range.
-- The examples corpus is broad, but not curated into a first-session sequence.
-
-## Design Principles
-
-1. **The first screen should contain intent.** A code box with no project story makes ForgeCAD feel like a compiler, not a tool.
-2. **Curate before catalog.** First-run should show three chosen files, not every example.
-3. **Teach the loop, not the whole product.** The first session is edit -> run -> inspect -> move local.
-4. **The CLI is the serious workflow.** Hosted onboarding should point users toward local files, agents, validation, rendering, and project sync.
-5. **Docs should be layered.** Welcome first, CLI second, API reference only when the user has a concrete modeling question.
-6. **Do not point first-run users at package internals.** If examples are part of onboarding, they need a hosted docs/gallery surface, public repo link, or seeded project file the user can actually open.
-
-## Target Experience
-
-### Browser First Run
-
-When a hosted user with zero projects opens `/app`, ForgeCAD creates:
-
-```text
-Start Here/
-  00-start-here.forge.js
-  01-parametric-bracket.forge.js
-  02-assembly-basics.forge.js
-```
-
-The first file is active. It should be short, runnable, and friendly inside the code itself. The user can change dimensions and immediately see the model update.
-
-### Docs Welcome Page
-
-`/docs/welcome` is the public first-session docs page. It should answer:
-
-- What am I looking at?
-- What should I try first?
-- How do I move this project to the CLI?
-- How do I use an AI coding agent with ForgeCAD?
-- Where do I go after the first 10 minutes?
-
-### CLI Bridge
-
-The Welcome page and starter file both point to this path:
-
-```bash
-npm install -g forgecad
-forgecad login
-forgecad project clone start-here
-cd start-here
-forgecad studio .
-```
-
-For GitHub/Google accounts, choose API token during `forgecad login`. API tokens are available from Settings > API Tokens.
-
-## Friction to Experiment Map
-
-| Friction | Profiles affected | Experiment | Priority |
-|---|---|---|---|
-| New account opens an empty project | Alex, Maya, Sam, Priya | Create `Start Here` starter project when an account has zero projects | P0 |
-| Docs are reference-first | Alex, Maya, Sam | Add `/docs/welcome` before API sections | P0 |
-| CLI is not introduced at the moment of need | Alex, Sam | Put clone/studio/run commands in starter file and Welcome page | P0 |
-| Full examples are too broad for first contact | Maya, Priya | Curate three starter files instead of opening examples project | P0 |
-| AI-agent workflow is disconnected | Alex, Sam | Welcome page points to `forgecad skill install` and CLI validation loop | P1 |
-| No first-run instrumentation | All | Add analytics/audit event for starter project creation and first CLI token creation | P1 |
-
-## Implementation Map
-
-### Source-of-Truth Surfaces
-
-| Surface | Role | Owner |
-|---|---|---|
-| `docs/permanent/product/onboarding-first-experience.md` | Product source of truth | Product/engineering |
-| `docs/permanent/welcome.md` | User-facing Welcome docs page | Product/engineering |
-| `server/onboarding/starterProject.ts` | Starter project file template | Engineering |
-| `src/pages/DocsPage.tsx` | Docs navigation and route registration | Engineering |
-| `src/App.tsx` and `src/fs/HostedStudioProvider.ts` | Zero-project redirect/create behavior | Engineering |
-
-### First Implementation
-
-1. Add a `starter` project template option to `POST /api/projects`.
-2. Keep normal "New Project" behavior blank by default.
-3. Use `template: "starter"` only when the hosted app detects a user with zero projects.
-4. Add starter files server-side so the first project works even if the browser reloads immediately.
-5. Add `/docs/welcome` to the docs nav and search index.
-
-### Local Preview Note
-
-`npm run dev:studio` starts the hosted frontend only. It can show `/docs/welcome`, but it cannot create the hosted `Start Here` project unless the Fastify backend and Postgres are also running. To test starter project creation locally, run the hosted backend stack and open `/app` with a fresh account or empty project list.
-
-### Later Improvements
-
-- Add a first-run modal only if the starter project and docs page are not enough.
-- Add a hosted examples gallery later, separate from first-run. Until then, link to public repo examples instead of npm package paths.
-- Add "Clone locally" and "Create API token" affordances in the editor toolbar once the base path is proven.
-- Add first-run metrics: starter project created, first file opened, first save, first CLI token created, first project clone.
-
-## Non-Goals
-
-- Do not design a full tutorials system yet.
-- Do not open the entire examples project for new hosted accounts.
-- Do not add gamified checklists or badges.
-- Do not require the CLI before the browser gives immediate value.
-- Do not restore implicit local studio examples; `forgecad studio ./examples` should be explicit and `forgecad studio` without a project path should fail.
-
-## Risks and Mitigations
-
-| Risk | Mitigation |
-|---|---|
-| Starter files become stale as APIs evolve | Treat starter files like examples and run them through smoke checks. |
-| Users think the browser is the whole product | Put CLI path in the starter file and Welcome page. |
-| Users who want blank projects dislike seeded files | Only seed the first zero-project account path. Manual New Project stays blank. |
-| Docs page becomes too broad | Keep Welcome short and route API details to existing docs sections. |
-| Starter project creation fails | Fall back to the existing project path, but log/audit failures once observability is added. |
-
-## Validation
-
-The first implementation is good enough when:
-
-- A new hosted account with zero projects opens `/app` and lands in `Start Here`.
-- The project contains exactly the curated starter files.
-- The active file is `00-start-here.forge.js`.
-- `/docs/welcome` appears before API Reference in the docs sidebar and index.
-- The Welcome page includes the CLI login/token/project clone path.
-- The Welcome page does not tell users to browse npm package internals for examples.
-- Existing manual project creation still creates blank projects.
-
-## Experiment Log
-
-| Date | Change | Result |
-|---|---|---|
-| 2026-04-29 | Created this source-of-truth document and planned the P0 first-run path. | Done |
-| 2026-04-29 | Added `/docs/welcome` and wired zero-project hosted accounts to a server-side `Start Here` starter template. | Done |

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

@@ -1,17 +0,0 @@
-# Product Loop
-
-ForgeCAD's core product loop is:
-
-```text
-user goal -> AI edits .forge.js -> run -> render or inspect -> fix -> sweep params -> export or publish
-```
-
-This loop is the product. The editor, CLI, docs, hosted projects, skills, examples, exports, and inspection bundles should all make this loop faster and more trustworthy.
-
-The loop matters because AI will be wrong. The product promise is not that an agent invents perfect CAD on the first try. The promise is that the agent works inside a system that catches syntax errors, missing imports, invalid geometry, bad parameter ranges, collisions, thin walls, broken assembly relationships, and export failures.
-
-For a normal user, this turns CAD from expert hand work into guided iteration. They can describe the object, inspect a render, change a parameter, reject an awkward result, and ask for a fix. For a technical user, the loop is also automation-friendly: files are plain source, outputs are deterministic enough to compare, and checks can run from the terminal.
-
-Every product investment should be measured against this loop. A feature that looks impressive but cannot be validated, edited, parameterized, exported, or explained by the agent is weaker than a boring feature that closes the loop for a real manufacturing job.
-
-The strongest future product surface will combine natural language, editable code, visual evidence, manufacturing constraints, and project history. The user should feel that the AI is doing the hard modeling work, while ForgeCAD is keeping the work understandable and grounded.

package/dist/docs-raw/product/strategic-decisions.md

@@ -1,22 +0,0 @@
-# Strategic Decisions
-
-ForgeCAD product decisions should start from the same question: does this make AI-authored physical design more reliable, useful, and commercially valuable?
-
-A strong product bet usually has five properties. It serves a clear user segment. It gives the AI better domain vocabulary. It creates validation evidence. It connects to a real output route. It strengthens a business path such as Pro usage, embedded commerce, OEM partnership, or enterprise pilot work.
-
-This means not every geometry feature deserves product priority. A kernel capability is not automatically a product feature. A product feature exists when it helps a user get a job done, helps an agent express intent, or helps the business own a valuable workflow.
-
-For example, CNC primitives should be judged by the manufacturing workflow they unlock. If they only add shapes, they are weak. If they let an agent express pockets, contours, drilling, stock, tool access, material constraints, and validation around a real CNC route, they may be strategically important.
-
-Similarly, better API docs are useful but are not always the product answer. If the same workaround appears repeatedly, the deeper issue may be missing product vocabulary. Documentation should make the product easier to use; it should not hide the absence of a first-class concept.
-
-Use this filter for new ideas:
-
-- Who is the first user who will care?
-- What object or workflow becomes possible that was hard before?
-- What does the AI no longer have to improvise?
-- What can ForgeCAD validate or inspect?
-- What output, partner, or revenue path does it strengthen?
-- What would make this feature obviously successful after one month?
-
-If those answers are weak, keep the idea as research. If they are strong, the product likely has a real direction to explore.