cli-tri checks out no submodules, so tri rtl check reads an empty chips/phi and emits 0 verdicts

[gHashTag]

cli-tri's build job checks out no submodules, so the design tri rtl check is pointed at is an empty directory.

This is the third sequential cause in the same job. #2303 hoisted the yosys install above the tests; #2305 assigned dry_run_sweep_ok, which was declared false and never set. With both fixed, cargo test -p tri reports 156 passed; 0 failed and the job advances to a step that had never executed once in the workflow's history:

./target/debug/tri rtl check chips/phi --json
Error: No such file or directory (os error 2)
verdict lines: 0
##[error]tri rtl check emitted 0 verdicts; five checks should each emit one

Cause

chips/phi is a gitlink (mode 160000) to gHashTag/tt-trinity-phi, pinned at f5456685c3593665153fe2765c85bb1f46ec14c2. .github/workflows/cli-tri.yml line 33 is a bare

      - uses: actions/checkout@v4

with no with: block, so submodules takes its default of false and chips/phi is an empty directory on the runner. The binary is fine; it has nothing to read.

The error is bare rather than descriptive because top_from_info in cli/tri/src/rtl.rs reads the file without context:

let text = std::fs::read_to_string(dir.join("info.yaml"))?;

while its sibling declared_sources wraps the same failure in .with_context(|| format!("no info.yaml at {}", ...)). The missing file therefore surfaces as an unattributed os error 2 instead of naming the path.

Why this is mechanical and not a secrets decision

submodules: true with the default GITHUB_TOKEN only works if the submodule is public — the token is scoped to this repository alone. All three submodules are public:

submodule	repo	private	size
chips/phi	gHashTag/tt-trinity-phi	false	941 KB
chips/euler	gHashTag/tt-trinity-euler	false	3,954 KB
chips/gamma	gHashTag/tt-trinity-gamma	false	5,365 KB

submodules: true pulls all three, ~10.2 MB total. None of the three has a nested .gitmodules, so recursive buys nothing and true is the minimal setting.

The pinned commit f5456685 is reachable in tt-trinity-phi (dated 2026-05-18), so the checkout resolves rather than failing on an orphaned gitlink.

The fix produces five real verdicts, not just a non-empty directory

Checked against the pinned commit, not main:

• info.yaml is present (3,830 bytes) and sets top_module: "tt_um_trinity_nano", so top_from_info resolves.
• It declares 49 source_files; src/ at that commit holds 51 .v files, and all 49 declared files resolve. Check 1, sources resolve, passes rather than merely emitting.

The remaining four checks come from a single yosys pass, and yosys is already on PATH from the install step #2303 added above this one.

Not in scope

The N < 5 assertion stays exactly as written. The step asserted five verdicts and got zero; that is the assertion doing its job. Making this check pass by expecting less is the failure this sequence has been closing. No other line of the workflow changes, and build is not being added to the required contexts.