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.
2. Design from validated research - engineering principles, formulas, calculations, material properties, manufacturing constraints, tolerances, and safety requirements.
3. Justify every value. Dimensions, geometries, connections, interfaces, loads, clearances, fasteners, materials and mechanical properties must all be realistic and technically defensible.
4. Never invent. No assumptions, invented specifications, arbitrary dimensions, fake mechanisms, or purely visual detail.
5. 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.

On Windows, run curl.exe instead of curl: in Windows PowerShell 5.1 curl is an alias for Invoke-WebRequest, which rejects curl options such as -sS. curl.exe is the real curl in every Windows shell.

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.