genesis-compiler 1.10.14 → 1.10.15

package/README.md

@@ -367,7 +367,9 @@ The same baseline keeps what the software builds fast and correct as it
 grows, through checks the agent makes and judges rather than numbers it must
 hit. A request, job or test costs in proportion to the rows it handles, never
 to stored history: the agent counts a list's, batch's or write's queries at a
-few rows and at a realistic number and finds what grows with the rows. Tests
+few rows and at a realistic number and finds what grows with the rows. Each
+read asks the store for exactly the rows the code uses, with filters, existence
+checks and counts in the query and pickers searching on the server. Tests
 take the time their work needs: the agent reads the suite's time and its
 slowest files and fixes where the time goes, prepares test databases once per
 run (usually from a stored snapshot checked by a digest, with the full
@@ -380,17 +382,17 @@ pre-existing, and a final run is one whole run of the pushed tree. Each declared
 constraint and protection is tried with one input that breaks it, access comes
 from the trusted context, and a change others depend on fails loudly where the
 old shape is still used. A short list names what is wrong in any context, such
-as a silently capped read, an edited migration that has run, an edited
-generated file, or tests against a real database. A time limit catches a hang;
-a slow check is measured and its cause fixed, never hidden by a longer limit,
-retries or smaller data. Coarse outer limits, such as a list making hundreds of
-queries or a suite running for hours, mark what is clearly broken; they are not
-targets. The baseline is the short form: the genesis-project skill's sanity
-checks guide (`references/sanity-checks.md`) gives each check's examples and
-outer limits and is read before the agent reports such work done, and each
-Stack piece's "Sanity checks with <stack>" guidance names the stack's own tools
-for them, such as its query counter, parallel test runner and strict loading
-mode.
+as a silently capped read, a read narrowed in code, an edited migration that has
+run, an edited generated file, or tests against a real database. A time limit
+catches a hang; a slow check is measured and its cause fixed, never hidden by a
+longer limit, retries or smaller data. Coarse outer limits, such as a list
+making hundreds of queries or a suite running for hours, mark what is clearly
+broken; they are not targets. The baseline is the short form: the
+genesis-project skill's sanity checks guide (`references/sanity-checks.md`)
+gives each check's examples and outer limits and is read before the agent
+reports such work done, and each Stack piece's "Sanity checks with <stack>"
+guidance names the stack's own tools for them, such as its query counter,
+parallel test runner and strict loading mode.
 
 The installed, versioned profile descriptions live in
 `profiles/engineering/*.md`. Straight Genesis users can inspect and select them

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "genesis-compiler",
-  "version": "1.10.14",
+  "version": "1.10.15",
   "type": "module",
   "description": "An agent-independent prompt, multi-language code-index, cleanup, and verification companion with project agent guidance.",
   "repository": {

package/plugins/genesis/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "genesis",
-  "version": "1.10.14",
+  "version": "1.10.15",
   "description": "Makes Codex aware of optional Genesis adoption for existing projects.",
   "author": {
     "name": "Mobily Enterprises"

package/profiles/engineering/baseline.md

@@ -2,17 +2,19 @@
 
 - Every implementation must be easy to reason about and be the smallest targeted change that fully satisfies the known requirements.
 - Prefer direct control flow, existing ownership boundaries, and established project or technology seams.
-- Do not overengineer or overcomplicate the solution. Do not add speculative abstractions, layers, dependencies, infrastructure, compatibility paths, distributed patterns, cryptography, enterprise patterns, or other advanced machinery unless an explicit requirement or a concrete constraint makes it necessary.
+- 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 a concrete constraint makes it necessary.
 - 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.
-- 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 instead of assuming 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 being read. A list that makes hundreds of queries, or a save that takes 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.
-- 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 its 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 and reuse them, 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, never touches a development or production database, and can run beside any other, so two identical runs give the same result; 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.
+- 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 being 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.
+- 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.
+- 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 its 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 two identical runs give the same result; 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.
+- A new test proves its behavior at the cheapest level; one that is mostly its own setup around one check is not acceptable.
 - 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.
-- A failing test is a defect to explain, in the product or in the 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 does cover it. A new test is seen to fail once, by breaking the behavior or reverting the fix.
+- A failing test is a defect to explain, in the product or in the 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.
 - 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 rather than ids the client sends, and a missing value, scope or collaborator refuses instead of allowing.
 - A change that other code depends on (a name, a default, a contract) fails loudly, naming its fix, wherever the old shape is still used, and every dependent project is booted and checked with it.
-- Never, whatever the context: cap a read its callers treat as complete; 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.
-- During implementation, run the relevant checks and batch related cases when they share setup. Follow the project's verification policy for broad or final checks; do not repeat them merely because an item finishes or a session resumes. Preserve required coverage and isolation.
-- Bound each long check by a time limit so it ends even when it hangs; write its complete output to a local file and preserve its exit status. Afterwards read concise counts, timings and actionable failure excerpts first, expanding evidence only when needed; never load full passing reports into agent context. Retain startup and cleanup failures; retry only after a change or new evidence justifies it.
+- 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.
+- 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.
+- Bound each long check by a time limit so a hang ends it; write its complete output to a local file and keep its exit status. Then read counts, timings and failure excerpts first, expanding only when needed; never load full passing reports into agent context. Retain startup and cleanup failures; retry only after a change or new evidence justifies it.
 - 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.
-- For browser verification, batch related actions and return only the relevant values or page region. Capture screenshots at meaningful visual checkpoints or failures, not after every action. Preserve required viewport, identity and security coverage; prefer existing automated cases for repeated checks.
-- These are the short form. Genesis's 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.
+- 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.
+- Genesis's 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.

package/prompts/review.txt

@@ -27,11 +27,22 @@ timing where one exists and the code path otherwise: a list or batch whose
 query count grows with its rows, an access check whose cost grows with stored
 history, a list, batch or write path never tested at realistic counts, test
 preparation that replays the migration history, tests that share drifting data
-or cannot run in parallel, and a time limit raised to absorb slowness. Report
+or cannot run in parallel, and a time limit raised to absorb slowness. Search
+for reads whose rows are then filtered, found, sliced or tested in code,
+pickers and lookups included, and for capped reads (the latest N, a default
+page) used as if complete: each belongs in the query unless the code shows the
+store cannot express it, and a capped one also loses every match past the cap,
+so report it as a defect, not only a cost. Report
 behavior a refactor dropped: operations, validation, permissions or edge cases
 the earlier code had and the current code lacks, and tests deleted or weakened
 with it. Report declared constraints and protections that nothing enforces, and
 access decided from ids the client sends rather than the trusted context.
+Judge the structure, not only the change, since a change can look fine alone
+in an application that lacks a layer: run the project's lint and checks and
+read what they report; ask whether every table has one owner, whether every
+query of a table goes through that owner, and whether an owner or repository
+layer exists at all; and report work over a whole population (every user,
+row or tenant) done inside a request rather than over the request's own rows.
 Judge each against the matching section and outer limit of
 `.agents/skills/genesis-project/references/sanity-checks.md`.
 

package/skills/genesis-project/SKILL.md

@@ -170,7 +170,10 @@ row counts and history that compares its query count at a few rows and at a
 realistic number. Read the run's preparation, suite and slowest-file timings
 with its counts; when one grows with the data, find the cause (a read per row,
 an access check sized by stored history, test preparation that replays
-migrations) before reporting completion. After a refactor, walk the behavior
+migrations) before reporting completion. Search the changed reads, pickers and
+lookups included, for rows filtered, found, sliced or tested in code and for a
+capped read used as if complete; move each into the query, or state in the code
+why the store cannot express it. After a refactor, walk the behavior
 list made before it and report any item that no longer holds. Before reporting
 data access, tests, a refactor, a screen or a release done, read the matching
 section of [the sanity checks guide](references/sanity-checks.md) and apply its

package/skills/genesis-project/references/sanity-checks.md

@@ -21,6 +21,8 @@ reporting data access, tests, a refactor, a screen or a release done.
 Each one silently loses data, protection or a whole run.
 
 - Cap a read its callers treat as complete: they act on a silent first page.
+- Narrow a broad or capped read in code: a broad one reads what it discards, a
+  capped one loses every match past the cap.
 - Drop a behavior, rule or access decision silently in a restructure.
 - Declare a constraint or protection that nothing enforces.
 - Let a client's ids or a missing value decide access.
@@ -32,6 +34,29 @@ Each one silently loses data, protection or a whole run.
 - Release a test's servers, processes or timers only where a timeout skips it.
 - Edit a generated file instead of its source: the next generation erases it.
 
+## Data: one owner per table
+
+**Good:** every table has one owner, a repository or resource module, and every
+query of the table goes through it, so the table's scoping, validation and
+locking live in one place. A request works on the rows it concerns; work over a
+whole population runs as a job in bounded chunks.
+
+**Check:** judge the structure, not only a change. Run the project's lint and
+checks and read what they report. For each table, name its owner and search for
+queries that reach the table from anywhere else: routes, services, another
+table's owner, raw SQL. Read each request path for work that covers every user,
+row or tenant (a recount, a backfill, a sweep) instead of the request's own
+rows. Each read and write path needs a test that seeds a second owner and sees
+its rows stay unseen and unchanged, write hooks and side effects included.
+
+**Examples:**
+- An application had no repository layer: each route queried the tables it
+  needed with its own copy of the tenant filter, and every change looked fine
+  in a review of that change alone.
+
+**Outer limit:** an application with no owner layer, a table written from
+several places, or a request whose work grows with the whole population.
+
 ## Data: loading a dataset
 
 **Good:** a list, page or report takes about as many queries for 10 rows as
@@ -65,18 +90,46 @@ Compare a response's size with what the screen shows of it.
 a quiet database, runs the same access check more than a few times per
 request, or returns megabytes for one screen is broken. Find the loop first.
 
+## Data: each read asks for the rows it uses
+
+**Good:** a read asks the data store for exactly the rows the code uses.
+Filtering, sorting, limits, existence checks and counts go in the query. A
+picker, lookup or autocomplete asks the server for the narrowed set, searching
+on the server, instead of loading a list and filtering it in the browser.
+
+**Check:** search for reads whose results are then filtered, found, sliced or
+tested in code (`filter`, `find`, `some`, `slice`, a loop that skips rows, a
+length taken to count rows or test for one), and for capped reads (the latest
+N, a default page, a fixed limit) used as if complete. Move each into the
+query, or the code states why the store cannot express it. A capped read
+narrowed afterwards also loses every match past the cap, so it is a
+correctness bug, not only a cost: seed more rows than the cap, with the oldest
+one matching, and see it found.
+
+**Examples:**
+- Pickers loaded the latest 200 records of every kind and kept one kind in
+  code: slow, and a matching record older than the newest 200 never appeared.
+
+**Outer limit:** a capped read narrowed in code is broken at any size.
+
 ## Data: saves, batches and background work
 
 **Good:** a batch writes each table in a few statements inside the owner's
 transaction, not one full create per row. Work nobody waits for runs as a
-scheduled or queued job in bounded chunks. A read request takes no lock and
-writes nothing. Two writers on the same records never produce a server error.
+scheduled or queued job in bounded chunks: it loops over units of work (a
+tenant, a user), one transaction each, never one around the whole run and
+never one per row. A read request takes no lock and writes nothing. Every path
+takes its locks in one order, parents before children, so two transactions
+never wait on each other. Two writers on the same records never produce a
+server error.
 
 **Check:** count a batch's statements at 10 items and at 500. Look for due work
 run inside whichever request comes first, and one long transaction around it.
 Find any lock or write a read path takes for one-time setup: read first, lock
-only on the rare unset path. Run two writers on the same records; a retried
-transaction must be safe to repeat.
+only on the rare unset path. Compare the order in which each path locks rows.
+Run two writers on the same records; a retried transaction must be safe to
+repeat, so HTTP calls, email and uploads go before or after it, or into an
+outbox row written inside it.
 
 **Examples:**
 - An import created each row through the full single-record create path, with
@@ -122,8 +175,8 @@ decision, or drops one only with the person's agreement.
 
 **Check:** before changing code, list its operations, inputs and their
 validation, permissions per role, states and edge cases, with the test covering
-each. Afterwards walk the list again with the original tests passing and their
-assertions unchanged. Compare per-file test counts before and after, and name
+each; pin what a path answers with a test before moving it. Afterwards walk the
+list again with the original tests passing and their assertions unchanged. Compare per-file test counts before and after, and name
 each removal. Search for what a removed caller was the only caller of. After a
 mechanical sweep, compare files changed with files expected and search for the
 old form. A new mechanism replaces the one already doing the job.
@@ -161,26 +214,50 @@ look green, or dozens of skips nobody can place.
 **Good:** tests take the time their work needs. Files run in parallel within
 the machine's test budget. Databases and fixtures are prepared once per run
 from a stored schema and seed, checked by a digest of their sources, and the
-full migration history is replayed once, as its own check. Builds and server starts happen once per run.
+full migration history is replayed once, as its own check. Builds and server
+starts happen once per run. Each test proves its behavior at the cheapest
+level that can: rules and calculations in a unit test; data, access and
+refusals in a server or integration test; a component's content and states in
+a component test. A browser test checks only what needs a real browser (a flow
+across screens, navigation, layout at the standard widths, focus, the real
+sign-in); a new browser check is an assertion in the existing test that already
+reaches that screen, and a new browser test file is for a new flow. The app's
+own delays (retry backoff, debounce, polling) run on a fake clock, never in
+real time.
 
 **Check:** after every run, read the suite time, each phase's time
 (preparation, import, sign-in, tests) and the slowest files. A wall time close
 to the sum of the files' times means they ran one at a time: find why. In a
 slow file, find where the time goes: repeated preparation, replayed
-migrations, fixed sleeps, polling, a process per test, repeated builds or
-sign-ins. Split test time into the app's request time and the harness's before
-choosing a fix. Remove exact repeats across CI jobs. Each sleep names the
-condition it waits for; wait for that. Compare each raised time limit with the
-measured need, and check a limit exists. Assert counts, not tight times.
+migrations, fixed sleeps, polling, a process per test, repeated builds,
+sign-ins or page loads. Split test time into the app's request time and the
+harness's before choosing a fix. Remove exact repeats across CI jobs. Each
+sleep names the condition it waits for; wait for that. Compare each raised
+time limit with the measured need, and check a limit exists. Assert counts,
+not tight times. Before adding a test, find the cheapest level that proves the
+behavior and the existing test that already pays its setup; after adding it,
+report its time, how much of that is setup, and the suite's time before and
+after. A test that is mostly setup around one check is in the wrong place:
+move the check, then see it fail once there. A test that changes its input to
+skip a wait (another error, a shorter path) stops proving the skipped path:
+advance the clock instead, unless another test already proves that path.
 
 **Examples:**
 - 359 tests ran one file at a time, 163 s in all, because the test command
   forced a concurrency of one.
 - Test databases were rebuilt by replaying every migration for each file.
 - Time limits were raised until slow tests passed, and the slowness stayed.
+- A new browser test file took 21 s for two cases checking what one card on a
+  page shows. A component test proves that in milliseconds, and the page's
+  existing browser test could carry the one layout assertion for nothing.
+- A browser test waited out the app's two retries of a failed request in real
+  time, 3 s on every run.
 
 **Outer limit:** a suite running for hours (a small app's for an hour),
-preparation in minutes, or a limit ten times the measured need.
+preparation in minutes, or a limit ten times the measured need. A new test
+whose time is mostly its own setup, for a check that a cheaper level or an
+existing test could make, is not acceptable: every run, by every person and
+agent, pays for it for as long as it exists.
 
 ## Tests: each owns what it uses
 

package/src/index/agent-skills.js

@@ -305,7 +305,10 @@ async function resolveLocator(locator) {
       : `genesis:${locator.path}`
   );
   const skill = await describeSkill(directory, source);
-  if (!skill) invalidSkill(`Selected Agent Skill is unavailable: ${directory}.`);
+  // A selected skill the installed package does not contain is missing from the project's dependencies, not malformed.
+  if (!skill) {
+    throw new GenesisError('AGENT_SKILL_UNAVAILABLE', `Selected Agent Skill is unavailable: ${directory}.`, { path: directory });
+  }
   return { ...skill, component: locator.component };
 }