@gspothq/cli 0.1.1 → 0.2.0

package/configurations/language/javascript/rules/JAVASCRIPT.md

@@ -1,37 +1,41 @@
 # JavaScript
 
-Keep development tooling out of production runtime imports. Keep inputs and side effects explicit.
-Validate external values where the program receives them, before sending them to a database or another service.
-These values include HTTP bodies, query strings, route params, headers, environment variables, and database rows.
-Also validate remote procedure call results, provider responses, file input, generated data sources, webhooks, and scheduled-job payloads.
-If a check and this file disagree, tell the user.
+Read this rule when you change JavaScript or TypeScript code.
+
+Keep development tools out of production runtime imports. Keep inputs and side effects explicit. Validate the
+values that the security rules list where the program receives them, before you send them to a database or another
+service.
 
 ## Runtime
 
-Use APIs supported by the runtime and version the project declares. Browser code targets the
-browsers and build pipeline the project declares. Before adding a build step that needs another
-runtime, update the declared runtime configuration and documentation.
+Use APIs supported by the runtime and version the project declares. Browser code follows the
+declared targets and build pipeline. Before adding a build step that needs another
+runtime, declare it in the configuration and documentation.
 
 ## Modules
 
-Keep existing CommonJS modules CommonJS unless the task includes migrating them. Keep side-effect
-imports rare and explain their required effect. Browser code imports no server implementation.
+Do not convert existing CommonJS modules unless the task includes migrating them. Keep side-effect
+imports rare and explain what each one does. Browser code imports no server implementation.
 
 ### Module conventions
 
 <!-- level: all -->
 
-- Prefer named imports and named exports.
-- Avoid mutable exports and default exports in application modules. Preserve a default export
+- Prefer named imports and exports.
+- Avoid mutable and default exports in application modules. Preserve a default export
   when a tool or framework requires it.
 - Do not create container classes or exported objects only to simulate a namespace.
-- Keep JSDoc `@typedef` declarations with their behavioral owner, following the project's folder
+- Keep JSDoc `@typedef` declarations in the module that uses them, following the project's folder
   arrangement. Share them through type imports when another module needs the contract.
 - Import the module that declares a symbol. A library can explicitly select index-only re-exports.
+- Name a namespace import after its file or package, such as `fileOne` for `file-one.js`.
+- Keep the exported name of an import. Add an alias only when two imports collide, and name it for its
+  domain, such as `DomesticatedCat`.
+- Use a default import only for a package that requires one, and name it for the exported value.
 
 ## Values
 
-- Use frozen objects or plain constant objects for fixed value sets.
+- Use frozen or plain constant objects for fixed value sets.
 - Avoid truthiness checks when `0`, `''`, `false`, `null`, and `undefined` mean different things.
 - Use `null` for a meaningful domain value and `undefined` for missing object properties.
 - Use `??` when only `null` and `undefined` require a fallback. Do not use `||` when an empty
@@ -41,14 +45,13 @@ imports rare and explain their required effect. Browser code imports no server i
 
 ## Objects and functions
 
-Use object literals for grouped arguments and destructure fields when it makes their use clearer.
+Use object literals for grouped arguments, and destructure fields when that makes the code clearer.
 A function that mutates its input names and documents that effect.
 
 ### Function conventions
 
 <!-- level: all -->
 
-- Use an options object for several related arguments.
 - Do not add optional parameters to hide a broken caller contract.
 - Use early returns when they make missing-value and error handling clearer.
 - Keep constructors small. Add inheritance only for a real runtime relationship.
@@ -57,4 +60,14 @@ A function that mutates its input names and documents that effect.
 ## Asynchronous work
 
 Await a promise that must finish before the next step. Release child processes, subscriptions,
-and other resources in `finally` or the API's cleanup mechanism.
+and other resources in `finally` or the cleanup mechanism of the API.
+
+## Workspaces
+
+<!-- level: all -->
+
+- Each workspace package builds itself. Its build file lives in it and imports only its own files.
+- Code outside a package uses its public entry points and its `package.json`, never its source files. Tests may read source files.
+- Declare each dependency in the workspace package that imports it, not in the root `package.json`.
+- Pass a value between packages through a declared setting or a public API, never a
+  file that a build writes.

package/configurations/language/javascript/rules/NODE.md

@@ -1,11 +1,11 @@
 # Node
 
-Rules that hold because the code runs on Node, whatever language the project uses.
+Read this rule when code runs on Node.
 
 ## Module resolution
 
 - Unbundled compiled TypeScript follows Node module resolution. Runtime imports must resolve
-  in the emitted output; a `.js` import can identify the corresponding TypeScript source.
+  in the compiled output; a `.js` import can name its TypeScript source.
 - Preserve the declared bundler or direct TypeScript execution contract when the project uses one.
 - Do not rely on CommonJS and ES module interop working by accident. A file declares its module format,
   through the package type field or its extension.

package/configurations/language/javascript/rules/PLAYWRIGHT.md

@@ -1,14 +1,16 @@
 # Playwright
 
+Read this rule when you write or change a Playwright test.
+
 ## Tests
 
 - Give each test a coherent user journey with independent setup and observable assertions.
 - Query by role and accessible name such as `getByRole('button', { name: 'Submit' })`, then by label,
   placeholder, or text.
 - Do not use fixed waits such as `waitForTimeout`. Wait for the visible state, response, or URL that proves
-  the operation completed. Network inactivity alone does not establish readiness.
-- Every test starts from a known state it creates through the application's real setup (API or
-  UI), not from shared seed data or another test's leftovers.
+  the operation finished. Network inactivity alone does not establish readiness.
+- Start every test from a known state that the application creates through its API or its UI.
+  Never start from shared seed data or leftovers.
 - Assertions use the auto-retrying `expect(locator)` matchers. No manual polling loops.
 - A test never reads or writes production data. The base URL and credentials come from the
   project configuration for each environment.
@@ -18,17 +20,16 @@
 - Keep shared setup in the test support folder. Introduce page objects only when
   several tests repeat the same interactions.
 - Reuse isolated authentication state for tests that do not exercise login. Login tests verify
-  the actual authentication journey. Keep account state isolated between concurrent workers.
+  the full authentication journey. Keep account state isolated between concurrent workers.
 
 ## Configuration
 
 - Use the configuration files declared by the repository. Name projects so failures identify
   their browser, viewport, or other relevant execution context.
-- Declare the retry policy in the project configuration. Report retried passes separately from
-  first-attempt passes.
-- Configure trace, screenshot, and video retention for the required diagnostics. Upload failure
+- Declare the retry policy in the project configuration. Report retried passes apart from
+  first-attempt ones.
+- Configure trace, screenshot, and video retention for the failure evidence the project needs. Upload failure
   artifacts, restrict access, and avoid capturing credentials or unrelated private data.
 - Enable parallel execution only when each test has its own accounts and mutable resources.
   Document any scenario that requires serial execution.
-- Test the production build for release acceptance. Use a development server only when development
-  the test covers that behavior.
+- Test the production build for release acceptance. Use a development server only for behavior that the production build lacks.

package/configurations/language/markdown/manifest.toml

@@ -1,85 +1,54 @@
 allowed_words = ["Markdown", "lychee"]
+
 [configuration]
-title = "Markdown"
 description = "Markdown files: markdownlint, Prettier, and fenced code blocks that must parse."
+title = "Markdown"
 
 [files]
 extensions = [".md", ".mdx"]
 
 [[tool]]
+mise = "npm:markdownlint-cli2"
 name = "markdownlint-cli2"
+npm = "markdownlint-cli2"
+replace = [".markdownlint-cli2.jsonc", ".markdownlint-cli2.yaml", ".markdownlint-cli2.cjs", ".markdownlint-cli2.mjs", ".markdownlint.json", ".markdownlint.jsonc", ".markdownlint.yaml", ".markdownlint.yml"]
 rule_url = "https://github.com/DavidAnson/markdownlint/blob/main/doc/{rule}.md"
 suppression = { marker = "\\bmarkdownlint-disable(?:-line|-next-line|-file)?\\b", reason = " -- (?<reason>\\S(?:[\\s\\S]*?\\S)?)\\s*(?:--!?>)?$" }
 version = "0.23.3"
-npm = "markdownlint-cli2"
-mise = "npm:markdownlint-cli2"
 version_command = ["--help"]
 version_exit_code = 2
 version_pattern = "markdownlint-cli2 v(\\d+\\.\\d+\\.\\d+)"
-[[tool.replace]]
-file = ".markdownlint-cli2.jsonc"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint-cli2.yaml"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint-cli2.cjs"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint-cli2.mjs"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint.json"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint.jsonc"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint.yaml"
-shared = false
-
-[[tool.replace]]
-file = ".markdownlint.yml"
-shared = false
 
 [[tool_file]]
+per_scope = true
 target = ".gspot/config/markdownlint.jsonc"
 tool = "markdownlint-cli2"
-per_scope = true
-rule_keys = [""]
 
 [[tool_file]]
-source = "markdownlint-cli2.mjs"
-target = ".gspot/config/markdownlint-cli2.mjs"
-tool = "markdownlint-cli2"
 per_scope = true
 pointer = { path = ".markdownlint-cli2.mjs", body = "export { default } from {target_module};", when = { configuration = "javascript" } }
+target = ".gspot/config/markdownlint-cli2.mjs"
+tool = "markdownlint-cli2"
 
 [[check]]
-name = "markdownlint"
-example = "A heading that jumps from level one to level three reports MD001. Change the later heading to level two."
-run_in_copy = true
-level = "recommended"
-stage = "commit"
 command = ["markdownlint-cli2", "--no-globs", "--config", "{tool_file:markdownlint-cli2}", "{files}"]
-fix = ["markdownlint-cli2", "--fix", "--no-globs", "--config", "{tool_file:markdownlint-cli2}", "{files}"]
+example = "A heading that jumps from level one to level three reports MD001. Change the later heading to level two."
 exit_codes = [1]
+fix = ["markdownlint-cli2", "--fix", "--no-globs", "--config", "{tool_file:markdownlint-cli2}", "{files}"]
+help = "Run `gspot check --fix` for the rules that fix themselves; read the rule name for the rest."
+level = "recommended"
+name = "markdownlint"
 output = { format = "markdownlint" }
+run_in_copy = true
+stage = "commit"
 summary = "Checks every Markdown file against markdownlint with the shipped rule set."
-why = "Markdown that lints the same everywhere renders the same everywhere."
-help = "Run gspot check --fix for the rules that fix themselves; read the rule name for the rest."
+why = "Consistent Markdown renders the same in every viewer."
 
 [[check]]
-name = "fences"
-example = "A code fence labeled `bash` containing `if then` reports invalid syntax. Correct the example to valid Bash. Use a text fence only when the block represents text rather than executable code."
+example = "A `bash` fence with `if then` reports a syntax error. Correct the Bash, or label the block `text` when it holds no code."
+help = "Fix the code, or label the block `text` when it holds prose."
 level = "recommended"
+name = "fences"
 stage = "commit"
 summary = "Checks JSON, JSONC, TOML, YAML, Bash, JavaScript, JSX, TypeScript, TSX, and Python code fences in Markdown (.md) files for syntax errors."
-why = "A code block that does not parse is documentation that lies about the code."
-help = "Fix the code in the block, or tag the block text when it is not code."
+why = "A code block that fails to parse shows readers a program that cannot run."