Repository navigation
Conversation
|
Size Report
Startup median (7 runs, lower is better):
|
There was a problem hiding this comment.
All reported issues were addressed across 18 files
Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
View guided diff | Turn on auto-fix | Re-trigger cubic
|
The code looks sound at cbd21be and CI is green (23 checks, none failing); there are no conflicts. I did not run the generator or the daemon Not blocking, take or leave: the stub host in seams.ts re-states the simulator-vs-runner split that The Cubic threads that still hold are the Could this be smaller? The PR adds about 1,730 net production lines, and roughly 140 lines of SCOPE_ROWS plus the page header in generate.ts are prose held in TypeScript and re-emitted unchanged, so the drift check guards text it does not decide. Would a hand-written capabilities.md with a generated region between markers work, where only the tables are filled and annotations.ts shrinks to row, label, commands and link? Then the prose fixes above become plain doc edits. Could the stub host also be built from the production composers ( Before merge, please fix the four holding threads and answer the smaller-design question. |
cbd21be to
02e1a6c
Compare
|
Rebased onto current main and pushed Holding threads — all four fixed and each thread answered and resolved:
Non-blocking list — all four taken:
Smaller design — I went the other way deliberately, for one reason: the annotations are no longer prose the drift check carries, they are inputs the generator validates. Also in this head, from the independent review (verdict was rework; all P1s and P2s addressed, cell qualifications now live in cells because models quote cells):
One thing I did not do: the cross-check's "General" asks (host OS/toolchain requirements, supported OS versions, signing/setup requirements as new content) mostly belong to other pages and are only reflected where a cell needed them (macOS audio host note, Screen Recording permission, clipboard build dependency). |
02e1a6c to
e9145dc
Compare
|
Round 2 addressed on First, an honest explanation for two of the four items: the round-1 follow-up fixes (the release.yml regenerate line, the Action Button / fold / TV clipboard cells) were authored but lost from the pushed head — my history-rebuild script snapshotted 1. P1 release restamp — the release step now runs
2. P2 mutation escape — plain 3. P2 quoted cells — Android TV emulator and Android TV / Fire OS clipboard cells now read "Build-dependent; unavailable on AOSP builds without 4. P2 HarmonyOS settings — both HarmonyOS cells now read "Clear app state only; other settings and reads unsupported", with Validation: |
The `capabilities` inventory decided command support from a device's runtime facts inside its own module. Move that rule into the command registry package, where the use requirements it reads already live, so every reader of the same facts answers the same way. The rule reads the command's declared uses itself, so a reader cannot compose the pair wrong, and it keeps its fail-closed guard: an operation the inspected owner does not state is unavailable.
The page answers which commands each target supports: iOS simulator and physical devices, Android emulator and devices, Android TV and Fire OS, tvOS, Vega OS, HarmonyOS, macOS desktop and apps, Linux, web, and the four hosted providers. Every cell comes from the same inspectFacts decision the `capabilities` command answers from, collected per target against a stub host and a scripted provider wire, so the page cannot claim a command the runtime would refuse. Cells answer at operation level: a Yes renders only while the target admits every operation the row advertises, and a qualified cell names its own operations when its text claims less, so removing one operation fails generation even when the command stays admitted through another use. The seam fails the run when a runtime starts deciding a cell from a host seam the matrix has not declared, and the web and Apple recording seams answer through the same composition the daemon builds. Rows, labels, limits, and doc links live in one annotations file keyed by command name.
Registers the check id `capabilities-matrix`, wired to the repo-guard that regenerates the page, diffs it, proves the drift report fires on a changed cell, and proves every Yes cell still names facts that hold, qualified or plain, at operation level. It runs in the docs lane before the checks that read the page, and the same guard rides unit-ci for source changes. The page's version stamp is compared, and the release workflow's version step regenerates the page after the bump, outside the captured version stdout, so the stamp moves inside the same version commit; only the generation date stays masked. The page's own path now selects the gate in the affected-checks model.
e9145dc to
87b4067
Compare
|
Round 3's single finding fixed on The rule, applied generally. Clipboard cells. All four Android clipboard cells (emulator, device, TV emulator, TV device) now declare Mutation tests extended in the repo-guard, all asserting generation throws:
The other cells that qualify a Yes by command only (Vega open/close, Action Button, fold) were already covered by the generator run against real facts: with the general rule active, generation renders the same page, so the operations their labels promise currently hold; and if any of them stops holding, generation now fails at that cell instead of re-rendering the sentence. Guard: 12/12. |
|
Thanks for the update. At 87b4067 the earlier findings from the first review are fixed, and I found no new blocking problem in the code. All 33 checks pass, and there are no conflicts. I did not run the generator or the repo-guard, so the mutation outcomes below are reasoned from the code. I also did not compare the columns against a live The four earlier P1/P2 threads that cubic raised on seams.ts, the matrix gate in unit-core, namingTarget and the Node API row look fixed at this head. So do the mergeLabel, docs.yml gate, perf/logs row and React scope threads. Please resolve them: #3942 (comment), #3942 (comment), #3942 (comment), #3942 (comment), #3942 (comment), #3942 (comment), #3942 (comment), #3942 (comment). Not blocking, and you can take or leave these: (1) answer() skips the advertised check whenever a qualification declares Could one rule replace the four overlapping guards ( The open item is the question above: please adopt the single partition rule or say why the four guards should stay. Either way, the HarmonyOS perf cells and a mutation for them would close the hole in the first note. |
Summary
Adds
website/docs/docs/capabilities.md: which commands each target supports — iOS sim/physical, Android emulator/physical, Android TV/Fire OS, tvOS, Vega OS, HarmonyOS, macOS desktop/app, Linux, web, and Limrun, BrowserStack, AWS Device Farm, TestMu AI sessions. Identical targets merge into one column; each row links to the doc section that proves it.Every cell is generated, not written:
scripts/capability-matrix/loads each platform/provider runtime against a stub host and a scripted provider wire, calls the sameinspectFacts(device)thecapabilitiescommand answers from, and maps facts to commands through the registry rule (command-registry/fact-support, extracted from thecapabilitiesinventory so both share one owner; it judges the declared uses given to it, so importing it adds no eagerly-loaded modules). Non-fact data (labels, limit notes, doc links) lives inannotations.tskeyed by command id, so removing or renaming a capability fails the gate. Host seams that decide cells fail closed: a runtime that starts reading a new seam fails the run rather than reading a fabricated answer.Also:
check:capabilities-matrixin the docs lane (regenerate-and-diff + repo-guard with negative proofs), sidebar + README links,llms.txtcoverage comes from the sidebar.Follow-ups, not blocked here:
<link rel="alternate" type="text/markdown">per page would need a@callstack/rspress-presetchange (.mdmirrors already ship andllms.txtlists the page).generate:capabilities --writewould fix it.perfframes/memory-snapshot available whilecommands.mdsays those report unavailable inside the run; a row note now says a Yes means the command runs, not every metric. Deciding the HarmonyOS facts themselves is separate work.Validation
cbd21be5d4(baseed798f9cfe):pnpm check:affected --run --head cbd21be5d4— all runnable checks passed,exactCommit=true(receipt.tmp/validation/run-QeHekO).🤖 Generated with Claude Code