genesis-compiler 1.10.15 → 1.10.16
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -2,19 +2,19 @@
|
|
|
2
2
|
|
|
3
3
|
- Every implementation must be easy to reason about and be the smallest targeted change that fully satisfies the known requirements.
|
|
4
4
|
- Prefer direct control flow, existing ownership boundaries, and established project or technology seams.
|
|
5
|
-
- Do not overengineer or overcomplicate: add no speculative abstractions, layers, dependencies, infrastructure, compatibility paths, distributed patterns, cryptography, enterprise patterns or other advanced machinery unless an explicit requirement or
|
|
5
|
+
- Do not overengineer or overcomplicate: add no speculative abstractions, layers, dependencies, infrastructure, compatibility paths, distributed patterns, cryptography, enterprise patterns or other advanced machinery unless an explicit requirement or concrete constraint needs it.
|
|
6
6
|
- If good software requires material complexity beyond these rules, stop before writing it. Explain the requirement, why the direct design is insufficient, and the smallest added complexity proposed, then ask the user to approve or clarify the tradeoff.
|
|
7
|
-
- A request, job or test costs what the rows it handles cost, never what stored history or the whole dataset costs; this is the direct design, not speculative scale work. Check it: count a list's, batch's or write's queries or storage calls at a few rows and at a realistic number, and judge whether the count follows the pages read or grows with the rows. A count that grows usually means a read, lookup or access check runs per row, or an access check is sized by stored history; related rows come in batches, one query per related table, and every visibility check is bounded by the rows
|
|
7
|
+
- A request, job or test costs what the rows it handles cost, never what stored history or the whole dataset costs; this is the direct design, not speculative scale work. Check it: count a list's, batch's or write's queries or storage calls at a few rows and at a realistic number, and judge whether the count follows the pages read or grows with the rows. A count that grows usually means a read, lookup or access check runs per row, or an access check is sized by stored history; related rows come in batches, one query per related table, and every visibility check is bounded by the rows read. A list making hundreds of queries, or a save taking tens of seconds, is broken: find the cause first. Such limits mark what is clearly broken; they are not targets, and code is never bent to reach a number.
|
|
8
8
|
- A read asks the store for exactly the rows the code uses: filters, sorting, limits, existence checks and counts go in the query, and pickers and lookups search on the server.
|
|
9
|
-
- Give list, batch and write paths a test at realistic row counts and history, since a handful of rows hides per-row work; it compares counts at two sizes rather than holding a fixed ceiling tuned until it passes. Tests take the time their work needs, no more: read the suite's total time and
|
|
9
|
+
- Give list, batch and write paths a test at realistic row counts and history, since a handful of rows hides per-row work; it compares counts at two sizes rather than holding a fixed ceiling tuned until it passes. Tests take the time their work needs, no more: read the suite's total time and slowest files, and find where a slow file's time goes (database preparation, replayed migrations, fixed sleeps, polling, server or build starts). Prepare databases and shared fixtures once per run, usually from a stored schema and seed snapshot checked by a digest of their sources rather than by replaying migrations, and keep the full-history migration proof as one separate check. Each test file owns its data, ports and files and can run beside any other, so identical runs agree; files run in parallel within the machine's test budget, and a suite whose wall time is close to the sum of its files' times ran them one at a time, so find why. A suite that runs for hours, or test preparation measured in minutes, is broken.
|
|
10
10
|
- A new test proves its behavior at the cheapest level; one that is mostly its own setup around one check is not acceptable.
|
|
11
11
|
- A refactor, consolidation or move keeps every behavior, or drops one only with the person's agreement. Before changing code, list what it does (its operations, inputs and their validation, permissions, states and edge cases) with the test covering each, adding one where none does; afterwards walk the list again, with the original tests passing and their assertions unchanged. A change that deletes tests or weakens their assertions is not a refactor.
|
|
12
|
-
- A failing test is a defect to explain, in
|
|
13
|
-
- Every constraint and protection the code declares is enforced: send one input that breaks each (a missing required field, a call past a rate limit, a caller without permission, another tenant's id) and see it refused. Authorization is decided before validation answers, from the trusted context
|
|
14
|
-
- A change
|
|
15
|
-
- Never, whatever the context: cap a read its callers treat as complete, or narrow a broad or capped read in code; drop a behavior, rule or access decision silently; declare a constraint or protection that nothing enforces; let a client's ids or a missing value decide access; store a missing value as a real one; run tests against a developer's or production database or configuration; edit a migration that has run anywhere; edit a generated file instead of its source; let the first visitor to a new deployment own it; run production with development settings; release a test's servers, processes or timers only where a timeout skips it. Each one silently loses data, protection or a whole run.
|
|
12
|
+
- A failing test is a defect to explain, in product or test, never noise or a "pre-existing" baseline: do not rerun it until it passes, skip it or loosen it to finish. A final run is one run of the whole suite on the tree that is pushed; reruns, chunks and partial runs are reported as partial. A skipped test records its reason and the run that covers it. A new test is seen to fail once, by breaking the behavior or reverting the fix.
|
|
13
|
+
- Every constraint and protection the code declares is enforced: send one input that breaks each (a missing required field, a call past a rate limit, a caller without permission, another tenant's id) and see it refused. Authorization is decided before validation answers, from the trusted context, not ids the client sends, and a missing value, scope or collaborator refuses instead of allowing.
|
|
14
|
+
- A change other code depends on (a name, a default, a contract) fails loudly, naming its fix, wherever the old shape remains, and every dependent project is booted and checked with it.
|
|
15
|
+
- Never, whatever the context: cap a read its callers treat as complete, or narrow a broad or capped read in code; drop a behavior, rule or access decision silently; declare a constraint or protection that nothing enforces; let a client's ids or a missing value decide access; store a missing value as a real one; run tests against a developer's or production database or configuration; edit a migration that has run anywhere; edit a generated file instead of its source; let the first visitor to a new deployment own it; run production with development settings; release a test's servers, processes or timers only where a timeout skips it; stop a process by name or pattern (`pkill`, `killall`, `kill $(pgrep ...)`) instead of the pid you started. Each one silently loses data, protection or a whole run.
|
|
16
16
|
- During implementation, run the relevant checks, batching cases that share setup. Follow the project's verification policy for broad or final checks; do not repeat them just because an item finishes or a session resumes. Preserve required coverage and isolation.
|
|
17
|
-
- Bound each long check by a time limit so a hang ends it; write its
|
|
17
|
+
- Bound each long check by a time limit so a hang ends it; write its full output and exit status to a local file. Then read counts, timings and failure excerpts, expanding only when needed; never load full passing reports into context. Retain startup and cleanup failures; retry only after a change or new evidence justifies it.
|
|
18
18
|
- A time limit catches a hang; it does not fix slowness. When a check, test or request is slower than its work needs, measure where the time goes and fix the cause; never raise a time limit, add retries, repeat a call or shrink realistic data or coverage to make it pass.
|
|
19
19
|
- For browser verification, batch related actions, return only the relevant values or page region, and take screenshots at visual checkpoints or failures, not after every action. Preserve required viewport, identity and security coverage; prefer existing automated cases for repeated checks.
|
|
20
|
-
-
|
|
20
|
+
- The sanity checks guide (`.agents/skills/genesis-project/references/sanity-checks.md`) gives each check's examples and outer limits: read the section that applies before reporting data access, tests, a refactor, a screen or a release done, and apply it with the tools your Stack pieces name.
|
|
@@ -32,6 +32,9 @@ Each one silently loses data, protection or a whole run.
|
|
|
32
32
|
- Let the first visitor to a new deployment own it.
|
|
33
33
|
- Run production with development settings, fallbacks, hosts or secrets.
|
|
34
34
|
- Release a test's servers, processes or timers only where a timeout skips it.
|
|
35
|
+
- Stop a process by name or pattern (`pkill`, `killall`, `kill $(pgrep ...)`)
|
|
36
|
+
instead of the pid you started or the project's stop command: the match also
|
|
37
|
+
stops other projects' servers on the same machine.
|
|
35
38
|
- Edit a generated file instead of its source: the next generation erases it.
|
|
36
39
|
|
|
37
40
|
## Data: one owner per table
|