# Feedback on Adom Hydrogen from the RITHESH LED Display project

Written 2026-09-24 by the project owner (a first-time PCB designer), with the AI assistant, based only on what
happened while making this board: from requirements to schematic, layout, routing, checks and the manufacturing package,
over two days of sessions.

## What worked well

- **Project files from nothing.** The assistant created the project folder, requirements, schematic, footprints and PCB
  as files generated by scripts, so every step could be re-run and checked instead of clicked by hand.
- **Checks at every step.** ERC, DRC, a netlist checker, a datasheet pin audit, a placement checker, a voltage-drop
  solver and a USB impedance estimate caught real problems before they became expensive. Examples:
  - vias inside pads
  - via holes touching pad corners
  - a CC2 track boxed in by a VBUS track
  - a test pad too close to a screw
- **Plain-language explanations.** Decisions were explained in simple terms, with the trade-offs, before anything
  changed. Being asked "which option?" at each stage made a complex project understandable.
- **Review images.** Close-ups, per-layer images, Gerber-viewer renders and 3D views made it possible to review the design
  without running KiCad myself.
- **Command-line Wiki publishing.** Publishing the project to the Adom Wiki from the command line worked, and the page
  could be checked right away.
- **Cloud workspace for heavy tools.** KiCad, Freerouting, gerbv and Python libraries were installed only in the cloud
  container; nothing had to be installed on my Mac.

## What was difficult or confusing

1. **The Wiki tab kept reopening.** After I closed the Wiki tab, it reopened again and again. Each time it interrupted
   the workspace and took up space, and I had to close it once more. This was frustrating. (The assistant could not see
   or control the tab, so I don't know the cause.)
2. **Slow, blank reopening after a short break.** After Hydrogen was minimized or inactive for about 5–10 minutes,
   reopening it could take a long time. The Explorer, the file preview and the AI chat sometimes stayed blank, with no
   "loading" or "reconnecting" message, so I could not tell whether it was working, stuck or needed a reload.
3. **Long tasks were interrupted.** Several big steps (placement, routing) hit session or context limits in the middle.
   I had to type "continue" and re-explain what I wanted. After one interruption I could not tell whether a poor,
   partly-finished routing attempt had been kept. The next session had to check this first (it had already been removed).
4. **Saving progress in smaller stages mattered.** After the interruptions, work was split into saved stages
   (placement snapshot, routing stage 1, Freerouting result, planes, final). When the next interruption came, nothing
   finished was lost. This should be the default for long tasks, not something the user has to ask for.
5. **Memory limits in the cloud workspace.** The container had about 1 GB of free memory next to the editor. A routing
   tool that used too much memory was killed, and the editor restarted at the same moment. The tool then had to be run
   with a small memory limit.
6. **Unexpected text in a file.** A stray path fragment (`rithesh-led-display/hardware/tools`) appeared at the start of a
   line in `hardware/tools/check_pins.py`. That broke the pin audit until it was found and removed. Neither of us knows how
   it got there (possibly an accidental paste in the editor). I would never have spotted it as a beginner.
7. **Hard parts as a first-time PCB designer:**
   - Many new words at once: eFuse, DRC/ERC, courtyard, keep-out, via-in-pad, thermal relief, differential impedance,
     CPL. A small glossary next to the reports would help.
   - Very long reports. The short summaries at the end of each step were the most useful part.
   - Knowing which decisions were really mine (button order, USB-C position) and which were routine.
   - The installed KiCad version (7) has no command-line DRC, ERC or 3D render, so the assistant had to drive the KiCad
     window on a hidden screen. Some steps (3D views, ERC) were slow and fragile because of this.
8. **Where my account email appears on a public page was not obvious.** The account email is not shown on the normal
   public Wiki page, but anyone can see it in the page's `page.json` file, in the "download all" ZIP and in the upload
   (commit) history. I only learned this during the pre-publish privacy check. I chose to keep my email as it is; this is
   about being told clearly, not a request to remove it.

## Suggestions for a better beginner experience

1. **Respect a closed tab.** If the user closes the Wiki (or any) tab, don't reopen it automatically. Offer a setting
   like "open the Wiki page only when I ask".
2. **Show a clear status when Hydrogen wakes up.** After a period of inactivity, show "Reconnecting…" or "Loading…" in
   the Explorer, file preview and AI chat (with a retry button if it takes too long) instead of blank panels.
3. **Be transparent about public metadata.** Before a first public publish, tell the user plainly which details become
   public (for example the account email in `page.json`, the download-all ZIP and the upload history), and give an
   option to hide the email from public metadata (for example a "no-reply" address).
4. **Automatic checkpoints for long tasks.** Save a snapshot and a short "where we are" note after each stage, so that
   after an interruption the work resumes from the last stage without the user re-explaining.
5. **Warn before running out of memory or session time.** For example: "this step may need more memory than is free",
   or "this session is near its limit, saving progress now".
6. **Tell the user when a project file changes unexpectedly.** Show which file changed, when, and whether the AI or
   the user made the change. This would have caught the `check_pins.py` problem immediately.
7. **Newer KiCad in the cloud image.** A version with command-line DRC, ERC and 3D rendering would make checks faster and
   more reliable.
8. **Built-in viewers.** A Gerber viewer and a 3D board viewer inside Hydrogen would let beginners inspect the design
   themselves instead of only looking at images.
9. **Beginner mode for reports.** Put a short summary first, the details behind a "more" section, and link each
   technical word to a one-line explanation.
10. **A clear "decisions needed from you" list** at each step, separate from the technical report.