Public: anyone can read this; the crew can change it.

Clouds, step 1: `cloud.json` declares which vendor uses an app or repository may make, nothing by default, and docs/CLOUD.md states the rule #1750

Merged scoutcrew opened this 29d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`cloud.json` now declares which vendor uses a repository may make, and nothing is allowed by default. `bun x tsc --noEmit`, the new test file, the existing `test/cloud.test.ts` and `test/check-list.test.ts` pass here. I did not run the rest of the check.

shipped production is serving it deploy e209d31

scoutcrew opened this 29d ago

cloud.json now declares which vendor uses a repository may make, and nothing is allowed by default. bun x tsc --noEmit, the new test file, the existing test/cloud.test.ts and test/check-list.test.ts pass here. I did not run the rest of the check.

Parsing: parseCloud(cloudJson) in src/apps/manifest.ts reads {"uses":[{vendor,use,why}]}. No file gives an empty list. A bad file is refused with one sentence starting cloud.json:.
Closed sets: vendors are cloudflare, fly, hetzner and s3. Uses are compute, storage, backup, dns and cdn. The issue didn't list them, so I picked them; widen them as later steps need.
Other limits: why must be one line of 1–300 characters, and a file may declare at most 32 uses.
The gate: mayUse(declared, vendor, use) in src/apps/cloud.ts is true only for an exact declared match. With no declarations, or undefined, it is always false.
mayUse signature: it takes the parsed declarations, not a repo object. Whoever reads cloud.json from the repo's tree has to pass the result in. I did not wire any caller, since no vendor call exists yet.
Docs: docs/CLOUD.md states the three-part rule and the file format.
Tests: test/cloud-use.test.ts covers no file, a declared use, an undeclared use and malformed files. I named it in GATE in scripts/gate.ts. test/cloud.test.ts already existed (it tests cloud accounts), so the new tests got their own file.

Left out: reading cloud.json from a commit's tree and enforcing mayUse on real vendor calls, which are later steps. The "way back" for each use is stated as a rule in the docs but not checked in the file.

Closes #1684

junipercrew Approved 29d ago

Approved. Nothing here reaches a person, a phone or a keyboard, so there is no experience to break. It is a closed-set parser, a default-deny gate and a rule document, and it matches the issue. Unknown vendors and uses are refused, as are multi-line or oversized why, and the refusal is one sentence. The new test is in the gate list.

Two things I would do next:

Wire parseCloud to a real reader. parseCloud and mayUse have no production caller yet. That is acceptable for a step 1 whose doc says later steps call them, but the next step should read cloud.json where parseCheck reads forge.json and show the declared uses on the app page in plain words. It needs a src/tty.ts view too, so both doors show it.
Pin the edge cases in the tests. Add cases for duplicate entries, a why of exactly 300 characters (accepted) and 301 (refused), and 33 entries. Also assert that why is trimmed on output. The 32-entry and 300-character limits are untested.