wiki

Design wiki

A knowledge base, not a workflow and not a gate. It holds the engineering the CAD tooling does not know: which joint to draw, what makes a shaft stiff enough, which numbers make a linkage turn, and why a correct-looking printed mechanism still does not run. It writes no geometry and changes no other skill.

W="$(workshop skills path)/wiki/scripts/wiki"   # stdlib only: python3 or .venv/bin/python
$W search <words...>                 # ranked sections, path:line, snippet
$W search spindle --pages            # one line per page; synonyms expand
$W show <slug>[#section]             # print a page or one section
$W list [--tag gear]
$W new <topic>/<slug> --title "..."  # page from the template
$W lint                              # must pass before a wiki edit is done

Inside a Workshop product run the wiki is consult-only. Its bytes are materialized read-only and bound into the run's input manifest like every other skill, so new, a page edit and a synonyms.txt edit are all refused there — and a run that tampered with them would fail its resume. Search, show and list freely; step 5 below does not apply in a run. Append a rule the wiki lacked, with its evidence, to LESSON-PROPOSALS.md at the run root; the host's Make lessons loop carries gate failures into the design vault, and the Workshop build loop writes durable rules back to this wiki upstream. Paths written skills/<name>/... in these pages name a sibling Make skill: read them under "$(workshop skills path)/<name>/". Upstream's step-to-source and stl-to-step are not Workshop skills: a reverse-engineering/ page that names them describes tooling a run does not have, and its rules stand without it. Machines and fixtures the pages cite by name live in the upstream autonomous-product-to-cad repository, not in a product run; the numbers quoted are the whole example.

The loop: search, think, design, write back

1. Search before deciding. Whenever a part turns, slides, swings, latches, carries load or is driven, search the wiki for the joint, the element and the failure first — search shaft deflection, search keyed phase, search worm back-drive. Start a new machine at show mechanism-design, which holds the design sequence and the archetype chooser.
2. Read the hits, not the whole wiki. Open the two or three sections the search ranks highest with show slug#section and follow their [[links]] only where the design needs them.
3. Think with the page's numbers. Turn each rule you use into the project's parameter block and an assert (every page gives its assert). A decision you cannot write as a number or an assert is not designed yet. Record in the spec which page each archetype, fit and limit came from.
4. Design the system in this order — archetype → shaft and joint layout → parameters → feasibility asserts → kinematics → motion checks — and do not start geometry until the asserts pass.
5. Write back what you learned. Creating or editing any item ends here: when research, a calculation, a measurement, a gate failure, a kernel workaround or a user correction produces a rule the wiki did not have, add it before the task ends (below). When a search missed a page that exists, add the missing term to that page's aliases or to synonyms.txt.