Develop - #29
Merged
Merged
Conversation
…ocuments repeated the refusal, and a gate asserted the sentence so it could not be edited in one place The argument the refusal rested on is sound and is not the same as the refusal. Almost nothing here is local, so a patch to a contract, a token or a gate changes a rule binding every component and arrives without the argument that rule needs. What follows from that is not that the patch is unwelcome. It is that the argument has to travel, and it has to travel first only when the change reaches that far. So the route now splits by what a change binds rather than by who wrote it. A defect inside one component, one document, one manifest or one suite opens a pull request and waits for nobody. A change to a rule opens the third issue form, which asks for what a patch cannot carry: what Arena cannot do today, what it costs a project already on it, and which shapes were weighed and refused. A refused option without its reason is worth nothing, which is the standard DOUBTS.md already holds a decision to. check:community asserted the old sentence in exactly one document, so the reversal is a claim swap rather than a deletion: POLICY states the opposite thing and still has one home, and the templates still link it rather than restating it. OUTWARD gains the two files a stranger now meets, each with the reason it exists, which is what makes missingProblems notice either one going. A vulnerability had a private channel to arrive through and no channel to be fixed through, so the one contributor who had already read the code was told to stop there. A draft advisory carries a private fork, and that fork is the one place a patch for an unpublished defect is written, reviewed and run against the gates. The terms were nowhere. A repository that takes work from strangers and names no address for a report about conduct answers nothing at the moment it has to, so CODE_OF_CONDUCT.md is the Contributor Covenant and names one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K5g6JqMGvHS3zg6nCMwhio
…low that would now have run on it billed three operating systems per revision of every contribution Arena PR fired on pull requests targeting main alone, and work reaches main as one merge of develop. Every pull request a contributor opens targets develop, so the event that was meant to guard a change was the event that never saw one: what verified a merge into develop was Arena develop, after the fact, on a branch the change had already reached. Adding develop to the trigger closes that and moves a cost. The operating system matrix was priced against an event that happens once per release, and on this one it happens once per push to every open pull request, from anyone. So the matrix moves to the merge into develop, where it is asked once per change that was accepted rather than once per revision of every change that was proposed. What that costs is stated rather than discovered, because needs does not cross workflows: pr-gate reads no platform result any more, and no required check on a merge request to main answers a question about three operating systems. What carries the answer instead is the branch, since a merge request from develop to main is opened on a green develop. check-portability holds the matrix against supported-os.ts in develop.yml and pr-gate's needs against every other job in pr.yml, which is two files holding one rule each. Two suites asserted the old arrangement by literal value, one of them naming the reason the matrix sat where it did. Both now assert the new one and the reason it moved, so neither is a clause that stopped exercising anything. The release route pays for the paragraphs that say so. Its budget rises with the reason: a reader cutting a release who does not know where the matrix runs reads a green required check as an answer about three platforms, and it is an answer about one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K5g6JqMGvHS3zg6nCMwhio
…h at all, and git reads no path as every path The guard job installs nothing, which is deliberate: the question it asks costs less than the install would. package-inputs.ts reached CSS_CHAIN through package-assembly.ts, and that file imports typescript, tailwind and the token generator, so the job resolved typescript from the registry at 7.x against a tree that pins 6.x and the import threw. Nothing went red. The call sat in `mapfile -t SPECS < <(...)`, and set -e never sees a command inside a process substitution; an empty array expands to nothing under set -u; and git reads a diff with no pathspec as a diff of every path. So the guard answered "everything moved" and published, twice, from a diff of the whole tree: 145 files at 10.0.1 and 211 at 10.1.0, README, .claude-plugin and every scripts/ edit among them. Both releases did change both packages, so nothing wrong reached the registry. What was wrong is that no answer had been computed. The rule now sits apart from the copy that honours it. package-exclusions.ts carries EXCLUDED_NAMES, EXCLUDED_PATTERNS and excluded() and imports nothing, so "would this file ship?" is answerable in a job that installed nothing; package-assembly.ts re-exports all three, so the rule is still found beside the copy. An unreadable list stops the run rather than widening it. The list is read into a variable whose failure is checked and whose emptiness is checked, because a list this step could not read is a broken script and never a state. A spec names a directory, and a directory holds the suites beside the sources, the prompts and the prose no package carries. --carried drops those through the assembler's own excluded(), so the guard and the tarball answer from one list rather than from a second set of globs somebody keeps in step. The question goes to the part of a path INSIDE the spec that reached it: a spec naming a file is read rather than walked, and scripts/build/react/build-react-package.ts is the assembler of the package it belongs to, sitting under a directory called build, which is one of the names that walk skips. Asked of every segment instead, it drops each assembler from its own input list. The list was also short in the other direction. copyBehaviourContracts writes contracts/behaviour/ whole into both packages and no spec named it, so a contract edited alone changed both tarballs and reached no guard. Four of them changed between 10.0.1 and 10.1.0. Its coverage is now asserted against BEHAVIOUR_DIR, next to the assertions for the CSS chain and the CLI. check:workflow-scripts refuses the combination that started this. A job that runs a script either installs first or runs a script whose transitive imports are node: builtins and files in this tree. It reads a job rather than a workflow, since installing in one says nothing about another; it follows `bun run` through package.json so a name cannot hide a path, and stops rather than hangs on two names that run each other; and it takes specifiers off the parse, because `export const MANIFEST_IMPORT = /import manifest from '...'/` is a regular expression whose source is an import statement, and every scan short of a parser -- this repository's own and typescript's preProcessFile both -- reports its character class as a package. Reintroducing the deleted import fails it, naming typescript in two files and style-dictionary in a third. Two routes pay for the paragraphs. The gate route rises by one row, which is the ordinary case its budget is written around, and the row runs long because its claim is a failure this tree has already paid for. The release route rises because a reader cutting a release has to know that "nothing this package carries has moved" is a real answer and not a fault: the version of this guard that could not read its own list wrote publish into the run summary while republishing two unchanged trees, which is that route's failure mode exactly -- nothing errored, and nobody was told. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K5g6JqMGvHS3zg6nCMwhio
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
1 participant
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.
No description provided.