02 — User intent and requirements

The requirements arrived in pieces, often as short mid-turn messages, and were refined by later corrections. What worked: capture each one in the user's own words, turn it into a named feature or check, and recompute anything that depends on it.

Capture each mid-turn requirement verbatim and give it a feature

• Rule: Record each user requirement word for word, map it to the feature that satisfies it, and carry it through every later revision.
• Incident: During the first review the user added: "we need counter-sunk holes under the heat sink hole location because the heat sink is most of the mass of the assembly... so the heatsink mass is attached to our housing". This became the cooler tie-down: four printed columns under the 92 × 79 cooler holes, with flat-head screws driven up from under the floor. It was also saved as a standing project memory.
• Check: A requirements table lists each quote, its feature, its check and its status. The final report names every requirement.
• Source: 2026-10-24T07:07, 07:41.

Pin down what a screw threads into before computing its length

• Rule: For each fastener, identify the mating thread (part and feature) explicitly. Do not infer it from the part's general role.
• Incident: Rev 0.5 said that the tie-down screws thread "into the cooler", and asked the user to confirm the direction. The user corrected this: "the standoffs between the orin AGX and the heatsink have female threads. So our screw lengths ... need to go into those standoffs, that sets our lengths", and "(the screws through the base of the housing plastic go up into the standoffs)". The agent later listed "docs saying 'thread into the cooler'" as one of the session's mistakes.
• Check: The fastener table has a "threads into" column (for example "female standoff between AGX module and heatsink, thread starts at Z 40.76").
• Source: 2026-10-24T07:41; 2026-10-25T00:32, 02:18.

Derive values your own geometry sets; ask the user only for outside facts

• Rule: If a value follows from the model (stack heights, screw lengths), compute it and decide. Ask the user only for facts the model cannot supply, such as part identity or a physical measurement.
• Incident: Rev 0.5 asked for "the original screw's length + 19.6 mm". Later the agent asked whether to keep the head flush or raise it. The user: "the screw length is basically set by the top of the AGX and the bottom of the housing, assuming we just go something like 8 threads into the standoff", then "I can't give you the screw lenght, that depends on your assembly." The agent then made the call itself (M3 × 35 with a raised seat; see 04).
• Check: Before asking a question, test whether the answer is computable from parameters.json and the STEP. If it is, present a decision with its reasoning instead of a question.
• Source: 2026-10-24T07:41; 2026-10-25T00:34, 00:36, 00:37, 00:38.

Model every interface layer the user mentions, and recompute what it moves

• Rule: Add every stack-up layer as a named parameter (thermal pads, gaskets, washers), then recompute both the fasteners and the clearances it affects.
• Incident: The user: "(also watching out for thermal interface pad, standard thickness between heatsink and AGX)". A 0.5 mm pad became cooler.tim_thickness. It lifts the heatsink but not the start of the standoff thread, so the screw length is unchanged. It does take 0.5 mm off the cooler-to-roof gap: assembly-checks.json now reports 14.742 mm, where Rev 0.5.1 reported 15.24 mm.
• Check: Each layer has a nominal value and a "measure the fitted part" note. Dependent outputs (screw engagement, roof gap) are regenerated after any change to it.
• Source: 2026-10-25T00:34, 00:36; cad/parameters.json (tim_note); exports/assembly-checks.json.

Treat "doesn't block disassembly" as a hard requirement

• Rule: Before placing anything that is tethered to the internals, decide which part never comes off and attach it there.
• Incident: The user asked "where can we have RPSMA connectors for wifi and cellular without blocking disassembly?", then added "(2x each)" and "those are not mounted on the PCB, they would be extension cables with a RPSMA sticking through the housing with a nut". All four bulkheads went into the fixed base side walls, so the lid, both I/O plates and the side door lift away with the antennas still fitted.
• Check: For each removable part, list what is attached to it. No removable part may hold a cable that runs to the board.
• Source: 2026-10-24T16:35, 16:36, 17:10.

Turn a configuration list into named test cases

• Rule: When the user lists the configurations they want, make each one a named case in the check output.
• Incident: The user: "We want to be able to stack 1 or 2 of them and have them be 2.5" or 3.5" skinny 2.5" sata ssd or thick regular 3.5" hdd", then "(1 of each or 2 of each, or 1 total)", and "The cables can be exposed but need entry/exit points between the drives and the Orin carrier." storage-checks.json has seven named stacks, among them "1 total: 2.5 skinny SSDs on clips", "1 of each: 2.5 over 3.5, on plate" and "2 of each". Each one has its own plastic, hardware, chimney and bend-radius results.
• Check: Each case the user named appears in the check JSON with pass: true, and the review site shows it.
• Source: 2026-10-25T00:39, 00:40, 01:23; exports/storage-checks.json.

Report constraints that undercut the request, with a recommendation

• Rule: When a hard limit makes part of a request impractical (ports, power), say so plainly and recommend a default.
• Incident: After the 5 V finding the user asked: "Ok so this can only support the ssd SATA drives realistically?" The answer: yes, 2.5 in drives (SSD or spinning) run from the board, while 3.5 in drives need an added 12 V source. The board has only two SATA ports, so "2 of each" only makes sense with an M.2 SATA adapter. The agent recommended the 2.5 in tray as the standard option and offered to drop the 3.5 in tray.
• Check: Compare the number of drives in each configuration against the port count and the power budget (see 06).
• Source: 2026-10-25T01:34, 01:36.

Make "show it on the website" part of done

• Rule: For this user, a feature is not done until the review site shows it with evidence.
• Incident: Requests included "Also show them on the website..." (the drive options), "Launch the server again and show me how you are making progress", and "Where's the base for stacking with drives?". The last one was answered by stating that P1 is the stacking base and adding a "Which base do I print?" section. See 08.
• Check: Every change in the report links to the section or image on the site that shows it.
• Source: 2026-10-25T00:31, 00:40, 01:30, 01:36.