Robotics-club parts planner

IDEA 1

A bill of materials is a checkable proposal

A bill of materials lists the components a design needs. This toy robot requires one controller, one motor, and one power component. The input proposal names catalog IDs; the program reads each record to discover its kind, price, and stock rather than trusting the planner's description.

All compatibility rules are fictional pairs in a teacher-authored matrix. They are rules of this exercise, not electrical engineering guidance. We do not connect hardware, purchase parts, or claim the design is safe to build.

Separate the proposal from the catalog

1. Proposal. The supplied planner suggests three component IDs.
2. Read. Each ID must resolve to an actual fixture record.
3. Coverage. The observed kinds must cover every required component.
4. Bill. Keep the unique IDs and exact integer-cent total visible.

Toy catalog and synthetic costs; no real product recommendation or hardware control.

Check for a missing kind

const missing = input.requiredKinds.filter(kind => !parts.some(part => part.kind === kind));

The check uses kinds returned by the catalog. A proposal that labels itself complete cannot override an absent power component.

Think it through: The proposal says complete but contains no power component. Which evidence should decide?

IDEA 2

Cache reads, then verify the whole combination

A cache reuses a previously read record. In this lab the cache lives only for the current run and is keyed by part ID. If the proposal repeats an ID, one read is enough; this project's bill uses one unit of each unique ID rather than treating repeats as additional quantity.

Individual records are not enough to prove the combination works. checkCompatibility examines every pair under the fixture matrix, while priceParts checks total cost and stock. A negative checker result must override the planner's compatibility claim. Fewer calls matter only if required behavior still passes.

Reuse facts without skipping checks

1. Read once. The first motor-a request obtains its record.
2. Reuse. A repeated ID uses the cached record and does not add a second unit.
3. Pair check. Every proposed pair must appear in the authored compatibility matrix.
4. Price check. The known total must fit the budget with every item in stock.

The catalog is fixed during one run, which makes a per-run ID cache appropriate.

A negative verifier wins

const compatibility = tools.checkCompatibility(ids);
if (!compatibility.ok) return { status: "incompatible", ids, totalCents: null };

The result comes from the independent matrix, not the proposal's claimedCompatible field. Accepting the planner's claim would defeat the purpose of verification.

Think it through: Caching saves two reads, but the code skips compatibility checking. Is that a successful optimization?

IDEA 3

Keep a teacher at the order boundary

After coverage, compatibility, stock, and cost pass, the result is still a proposal. The synthetic teacher approval names the ordered unique part IDs. A preview for different IDs needs matching review.

The controller checks approval before a save call, and saveOrderPreview validates the same fixture scope again. If the call budget cannot support the next operation, the program returns budget with its partial bill. No real purchase or external write is possible in this lesson.

Checks before an approved preview

1. Feasible. Coverage, compatibility, stock, and cost have passed.
2. Review. Approval identifies the exact ordered set of unique IDs.
3. Preview. Only then may the local preview operation run.

Approval is a classroom field, and the saved artifact exists only in the run result.

Keep the save inside the budget

if (calls >= input.callBudget) return { status: "budget", ids, totalCents };
const saved = tools.saveOrderPreview(ids, input.approval.token);

Calls already spent are counted before starting the next operation. A partial result is preferable to silently exceeding the declared resource budget.

Think it through: A feasible bill has no teacher approval. Which result is appropriate?

Put it into practice

Read each unique part once, reject missing or incompatible combinations, and preview only a feasible approved bill within the budget.

1. Inspect the proposed IDs and required component kinds.
2. Run the starter against the incompatible case; notice that it trusts a proposal without the independent rejection gate.
3. Insert the compatibility-result guard.
4. Compare the trace for a proposal containing a repeated motor ID: it should still read only three records.
5. Reduce callBudget in the experiment and see an honest partial result before saving.

Your next experiment: Reduce callBudget from 6 to 5. Which result fields are already known when the save must stop?

Read actual records, verify the complete combination, preserve a finite budget, and keep a person at the action boundary.

Key terms

Bill of materials

A list of the components and quantities proposed for a design; this exercise uses one of each unique ID.

Compatibility matrix

An explicit table of allowed combinations; here it is a fictional classroom rule.

Cache

A stored observation reused within a declared key and lifetime to avoid another read.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.