DocumentationDesign knowledge and rules

THE CHIPPO GUIDE

Design knowledge and rules

From change evidence to project knowledge reviewed by engineers.

On this page

Three kinds of information

  • Observed facts: for example, a dimension changed between two values in a specific configuration.
  • User requirements: for example, every bracket in this project must use a specified hole spacing.
  • Inferences: for example, a guessed reason for the change. Mark it unverified unless supported by evidence.

One successful change does not establish a universal rule. Preserve sources, applicable objects, configurations, units, preconditions and validation status.

The review loop

Focusing a document establishes a baseline. Task and tool boundaries, saves and rebuilds capture bounded state. Comparisons stay within the same document and configuration; an incomplete capture does not treat unseen items as deleted. Evidence is stored in the project's .chippo/knowledge/observations.json.

At the end of the next Agent task, the selected model processes new evidence with relevant conversation and proposes at most three candidates. Saving or rebuilding does not trigger a separate model request. Insufficient evidence can produce no candidates.

Open Design knowledge (设计知识) in the sidebar to inspect pending candidates and their evidence. Edit the text, value, units, conditions and unverified matters, then accept or reject while the task is idle.

The recent-change summary lists captured parameter and material differences with their units and incomplete-capture warnings. It describes state changes without guessing why they happened; full structured evidence remains available to expand.

Candidates live in .chippo/knowledge/candidates/, separate from manual .chippo/rules.md. Only accepted candidates enter subsequent model calls as project rules. Conflicts require explicit review; superseded learned records retain their revision relationship, and manual rules are preserved. Rejected duplicates are not repeatedly proposed.

The reviewed-record view retains decisions. After extraction fails, the retry button schedules another attempt at the next task end rather than immediately making a model request. Archive limits produce an explicit error instead of silently deleting review history.

Physical claims

Claims about loads, materials, strength and clearance need operating conditions and validation evidence. Saving or rebuilding does not prove physical correctness. Project knowledge accumulation does not train model weights.

Documentation updated 2026-10-28
中文