sw-pre-start

SolidWorks Pre-Start

Run all phases in order. Do not model, generate CAD code, or call a SolidWorks

API until Phases 1 through 4 complete or a documented KB outage forces the

offline fallback.

Phase 0: non-negotiable engineering requirement (ENG-001)

This phase has no network dependency and is exempt from the offline fallback.

The KB carries the same rule as a convention, but a documented outage must never

be the reason it stops applying.

Do not create schematic, decorative, conceptual, simplified, placeholder, or

visually representative components.

**Every component must be a real, functional, manufacturable, technically

accurate part. No component - regardless of size or importance - may be created

merely for visual representation.**

For every individual component, including a single screw:

1. Research it against reliable technical sources: peer-reviewed papers,

engineering references, manufacturer documentation, and the latest

applicable standards.

1. Design from validated research - engineering principles, formulas,

calculations, material properties, manufacturing constraints, tolerances,

and safety requirements.

1. Justify every value. Dimensions, geometries, connections, interfaces, loads,

clearances, fasteners, materials and mechanical properties must all be

realistic and technically defensible.

1. Never invent. No assumptions, invented specifications, arbitrary dimensions,

fake mechanisms, or purely visual detail.

1. Cite the standards, formulas, calculations and references used for each part.

Model every physical component separately. If an assembly contains 10,000

parts, all 10,000 are researched, engineered and modelled individually. No group

of parts may be replaced by a simplified block, visual shell, placeholder,

texture, or symbolic representation. This covers screws, nuts, washers,

bearings, seals, cables, connectors, welds, joints, gears, springs, housings,

electronic components and internal mechanisms alike.

The finished design must be fully functional, physically realistic,

engineering-accurate, dimensionally consistent, manufacturable, properly

assembled, based on validated calculations, compliant with the latest applicable

standards, and free of decorative, fictional or representational parts.

When the information is not available

If sufficient technical information or reliable references are unavailable for a

component, do not fabricate or guess. State plainly what is missing and what

must be researched or specified before that component can be designed accurately.

Stopping to ask is the correct outcome. A plausible-looking part built from

invented numbers is a failure, not a partial success - it looks finished and

will therefore be trusted.

An offline KB makes this more likely to be the right answer, not less: losing

the standards tables means less grounding for a dimension, never permission to

invent one.

Set KB_HOST from SW_KB_HOST; default to

https://sw-plugin.ideep.org. Use curl through the shell for every runtime

request. Quote the complete URL. Do not use browser or web-fetch tools for this

KB.

Phase 1: conventions

Run:

curl -sS "{KB_HOST}/api/knowledge?kind=convention"

Load every returned body once per Codex task. Treat conventions as hard rules

unless the user explicitly overrides one. Read Persian and English documents.

Expect conventions for metric units, ISO 2768-mK defaults, material defaults,

fully-defined parametric sketches, PRJ-<part>-NNN naming, work/ and

exports/ paths, clean rebuilds, assigned material, rule checks, STEP, and

drawing PDF deliverables.

If required geometry or safety input remains unknown, ask the user; a KB

default does not authorize inventing geometry-driving values.

Phase 2: active design rules

Run:

curl -sS "{KB_HOST}/api/design-rules"

Skip entries with deprecated: true. Internalize the rest by category.

Enforce severity as follows:

• critical: block until resolved;
• high: fix before completion;
• medium: fix unless the user explicitly overrides;
• low: advisory, apply when possible.

Phase 3: task knowledge

Create a concise URL-encoded query for the requested component and likely

SolidWorks features, then run:

curl -sS "{KB_HOST}/api/knowledge/search?q={query}"

Read the top five to eight results, or up to ten for a complex assembly,

thread, or sheet-metal task. Prioritize playbook, then reference,

strategy, and convention. Read the complete reference for every SolidWorks

API method about to be used. Fetch a known document with

GET /api/knowledge/{slug} when necessary.

Phase 4: initial rule check

Build a JSON object from known values. Omit unknown keys; never fabricate them.

Typical fields are:

{
  "welded": false,
  "tolerance_class": "m",
  "process": "machined_aluminum",
  "wall_thickness_mm": 2.0,
  "nominal_dimension_mm": 50.0,
  "fastener": "M8",
  "hole_mm": 9.0,
  "material": "6061-T6"
}

POST it with curl:

curl -sS -X POST "{KB_HOST}/api/check-context" -H "Content-Type: application/json" --data-binary "@<context.json>"

React to each result:

• pass: continue;
• fail: stop CAD work and fix the input, explaining the rule and change;
• warn: flag it and fix when possible;
• advisory: apply it as a design constraint;
• na: ignore it.

Do not proceed while summary.fail is greater than zero.

Phase 5: standards on demand

Query only the table needed for the current decision:

• GET /api/standards/materials[/<name>] for density, yield, and modulus;
• GET /api/standards/fits for ISO 286 hole and shaft deviations;
• GET /api/standards/clearance_holes[/<designation>] for ISO 273 holes;
• GET /api/standards/tolerances_iso2768 for general tolerances;
• GET /api/standards/fasteners[/<designation>] for fastener geometry;
• GET /api/standards/sheet_metal_gauges for gauge thickness;
• GET /api/standards/preferred_numbers for R-series dimensions.

Record units. The KB database convention is mm, MPa, and g/cm3.

Phase 6: final rule check

After geometry is complete and before final save or export, POST a more

complete final context to /api/check-context. Resolve every fail; document

all advisories in the session issues narrative.

Offline and error behavior

• Unreachable server: record `KB offline - proceeding without pre-start

checks` and continue using verified engineering context.

• Search 404: continue with available knowledge.
• Check-context 422: retry once with fewer fields, then continue and record

the issue.

• 5xx or timeout: skip the failed phase and record it.

The KB accelerates the task; it is not a gatekeeper.