Repository navigation
Conversation
The spec and every ticket that follows it cite these three decisions, so they exist before the code does. - ADR 0001, the VM query API: two functions (enumerate an object's own keys, get a module object by name), no prototype walk inside the API, and a stability promise of additive-only plus a fixture corpus, because the fork has no CI and makepad-script is not on crates.io. - ADR 0002, the analysis posture: answer host requests during a check, re-run every top-level fn with no arguments, and suppress exactly one message shape (no getter for field X on type nil), with the runs that measured it: nil * 2 and "hi " + nil are silent, n.field is not. - ADR 0003, download-first distribution: a pinned version, one notice and an output-channel explanation on failure, a fallback that never fails activation, and a pure resolver with injected inputs, because the fork has no CI and a Windows path with single backslashes does not survive JSON.
docs: three ADRs ahead of the Splash language server code (#3)
…#4) tools/splashcheck_golden.py: the runner. It finds the checker and the workspace the way tools/octo finds the tools it wraps, runs it once per bundle over --json, and renders each report as the text a golden holds: the app id, a digest of the sources the checker read, the declarations, and every finding ordered with its line, column, code and message. Comparing prints a unified diff and exits 1; a workspace without the checker or the apps names what is missing and exits 2, because a corpus that passes quietly when it cannot run is worse than no corpus. tools/splashcheck_corpus/: thirteen golden files - the OctoSense shell's eleven system apps plus the AppCard assistant, and the fn blind-spot fixture that ships beside them so it is checked wherever the checker is. The fixture is `fn broken(){ let x = nope }`; the checker evaluates top-level code only, so its golden records no findings, which is the measurement the analysis-depth tickets flip. wasmlab is left out: it is a lab, not a system app. Two deliberate reductions, each commented where it happens: findings are sorted rather than listed in report order, and the VM's allocation counters are scrubbed, because a golden that churns on unrelated registry moves buries the change a reader came to see. The digest line is what tells a changed app from a changed checker, and each golden records the build that produced it. tools/test_splashcheck_golden.py: the runner's own contract, driven through run_checker with a canned checker and a synthetic corpus - record, compare, diff, update, and the honest exit 2 when the workspace is not prepared - plus the real corpus when this machine has it, and the corpus's structure as committed. .gitattributes: the fixture and the golden files are pinned byte-exact, so a core.autocrlf checkout cannot show a phantom digest diff. The checker and the apps are not in this repository, so nothing here changes the checker: the runner names the workspace it expects and reads the one contract the checker's own --json defines. The corpus is a local regression net, which the README states rather than leaves to be discovered. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
splashcheck golden corpus: the twelve real apps and the fn blind spot (#4)
Issue #2. A language server nobody can download is a language server nobody uses, so the first platform binary is published as a release asset whose name carries the server version and the platform: splash-lsp-2.0.0-x86_64-pc-windows-msvc.zip, under the tag splash-lsp-v2.0.0. The binary is built here, from the makepad revision the record pins, because the makepad fork has no CI of its own and distribution cannot depend on it. The record is the single source of truth the release workflow reads: the revision, the package, the features, the tag, and which platforms have an asset. Nothing is restated in the workflow, and a test asserts the two files agree in both directions, so a platform can be neither published unbuilt nor built unrecorded. Two runs of the workflow failed in about a minute each, which is the cheapest way either of these was learned. First: makepad patches octoscript-node to a path outside its own tree, so a checkout of makepad alone does not build. That sibling is the shared runtime this repository already locks in native-runtime.lock.json, so the record reads that lock rather than pinning the sibling a second time. Second: the binary is not in makepad's committed tree at the revision first recorded -- it lives on woshuoduijiushidui/makepad's feat/splashcheck branch, whose makepad-widgets is still 2.0.0, so the version stands and only the source pin moves. The build then asserts the sibling carries the crate makepad patches to; there is deliberately no stronger check that the sibling is the right one, because the shared runtime's makepad pin trails the server's and a mismatched node model fails the build loudly rather than shipping. Digests belong in the release notes rather than the record: a rebuilt binary is a different binary, so a digest committed in advance would only be a promise the next build breaks. macOS and Linux have no asset yet, and the record says so plainly rather than omitting them -- a downloader must be able to tell "not built for your platform" from "the network is down".
release: publish the splash-lsp server, and record the version it pins (#2)
Issue #9 shipped in OctoSense-org/makepad (platform/script, commit d34ceaf): the two functions ADR 0001 §1 fixes, spelled query::object_keys and query::module_object in a `query` module; the fixture corpus ADR 0001 §4 asks for, as one file in platform/script/tests with a runner per installing crate; and the stability promise as a checked-in surface file the test enforces, since the fork has no CI and the crate is not on crates.io. §4 gains a sentence recording the second runner: three of the six modules the ADR names are installed by the widgets crate's isolate setup, not by makepad-script. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue #9's code landed in the fork: OctoSense-org/makepad#123 (commit on
feat/vm-query-api). This records that in ADR 0001, the way #5's landing was recorded in ADR 0002.What changed
query::object_keysandquery::module_objectinplatform/script; the fixture corpusplatform/script/tests/query_corpus.txtwith a runner per installing crate; and the checked-in surface file thattests/query_api_surface.rsenforces, which is the semver check's equivalent for a crate with no CI and no crates.io release. Names the chain-walk proof ADR 0001 §2 asks for.querymodule, so the promised surface is one small file a reviewer can read in a sitting.cargo test -p makepad-script, because three of the six modules the ADR names are installed bymakepad-widgets' isolate setup rather than by the crate. The corpus keeps its home inplatform/script/tests/and gains a second runner, each entry naming its runner.Verification
tools/check-links.py: 0 broken, 0 pending. No other files move; the spec, GLOSSARY and flows are unchanged.Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com