04 — Invariants & tests

Summary

Five dimensions produce 240 combinations, which is not a test plan; separating what must always hold from what genuinely varies collapses it to 6 invariant assertions applied in every cell, plus 14 cells — I6 (publishing never changes the vault: publish, push, assert the object count unchanged) was added in the 18 Aug revision to catch the amplification loop. The invariants are behavioural checks, not code inspection — I2 asserts that no recorded request contained the key, rather than asserting the code doesn't send it. Two cells were re-scoped by measurement, and one (clone with no key at all) is structurally impossible by design.

Key concepts

• Assert behaviour, not absence of code — prove no request contained the key; don't restate the intent
• Structurally impossible ≠ untested — keyless clone can't name a file; the cell became mirror-with-manifest, with the no-manifest failure as part of the test
• Runtime-asserted platform facts — cell 10 asserts the CORS header at run time, so a platform change fails the suite instead of quietly breaking the feature

Key ideas

• 240 combinations → 6 assertions + 14 cells is the test-design move worth stealing.
• The fork round trip is the acceptance test.

Read the document