test: add a black-box architecture violation and repair proof
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 49/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, node.js, playwright, react, typescript, vite
- Domain
- build-system, testing, tooling
Research direction
Read the existing unit and integration tests, generator entry point, public CLI commands, and CI workflows to see how the project creates and validates a clean JST project. Build the proof in a temporary project, covering the two named violation families and asserting their stable diagnostic codes, reasons, repairs, and documentation links. Run npm run check and npm run test:e2e; done means the repaired project passes npm run validate and the proof cleans up temporary output on both success and failure.
Written by the indexing model from the issue text.
Description
Problem
JST has unit and integration coverage for individual rules, generators, SSR, and browser behavior, but it lacks one black-box proof of the complete user loop:
clean project
→ canonical generated slice
→ real architecture violation
→ actionable failure
→ repair
→ green project
Without this contract, a rule, generator, documentation example, or normal validation command can remain green independently while the promised end-to-end repair path is broken.
Scope
Add an executable proof that works against a temporary clean project and uses the same public commands documented for users.
The proof must:
- create a temporary clean JST project;
- run the real slice generator;
- verify the generated project is initially green;
- introduce a private cross-slice import violation;
- introduce an external-effect-in-view violation;
- run the normal validation command and assert actionable diagnostics;
- apply the documented repairs;
- verify the project returns to green.
Acceptance criteria
- The proof invokes public CLI/generator entry points rather than imported test-only internals.
- It verifies at least two independent violation families.
- The negative phase exits non-zero for the expected stable diagnostic codes.
- Diagnostics include a reason, repair, and stable documentation link.
- The repaired project passes
npm run validate. - Temporary output is removed after both success and failure.
- The proof performs no network access after dependencies are installed.
- It runs on Linux, macOS, and Windows in CI.
- Failure artifacts contain the command log and final diff, but not
node_modules. - The user-facing proof command completes within five minutes on the supported CI runners.
-
npm run checkandnpm run test:e2eremain green.
Dependency
Blocked by jst-stack/eslint-plugin#8. Do not bind this proof to complete human-readable error strings.
Design constraints
- Keep the harness outside application layers.
- Do not add production exports for the test.
- Keep fixtures minimal: they exist to prove the repair loop, not to become another showcase.
Out of scope
- Marketing copy, video, or GIF production.
- Artificially weakening the policy to simplify the demonstration.
- Testing every JST diagnostic; the conformance corpus owns exhaustive coverage.
Validation
npm ci
npm run check
npx playwright install chromium
npm run test:e2e
- Dominant language
- JavaScript
- Stars
- 1
- Forks
- 0
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 11
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from jst-stack/jst
-
enhancement help wanted javascript
Difficulty 5/5 Over a week Newbie friendliness 42/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
[quality] Nothing keeps docs/skills/manifest.md in sync with docs/skills/*.mdPossibly taken @hivecommons-hive claimed this today. Openagent/quality hive/covered-by-pr hive/hosted-available-lke648397-260827-5n31 quality testing
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
agent:blocked agent:ready
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
turbot/guardrails-fn#46 · 2 comments ·
Maintainers usually reply within 1 day
-
needs verification
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 6 days