v0.9.2: resource dropdown in org view, new library posts, removed unnecessary tests

.agents/skills/add-block/SKILL.md

@@ -902,16 +902,16 @@ Every block declares a one-line prose summary that replaces its card's field row
 
 ```
 Slack                                    ← header (already names the block)
-Posts ⟨Ship it 🚀⟩ to ⟨#eng⟩             ← the sentence; ⟨…⟩ are live value chips
+Post ⟨Ship it 🚀⟩ to ⟨#eng⟩              ← the sentence; ⟨…⟩ are live value chips
 ```
 
 Write one `byOperation` entry per operation dropdown option (or a single `default`
 when the block has no operation dropdown).
 
-**The full authoring contract — voice, structure, and the two mistakes that break
+**The full authoring contract — voice, structure, and the four mistakes that break
 cards silently — is `apps/sim/blocks/AGENTS.md` → "Canvas sentences". Read it
-before writing any.** The two failures worth repeating here, because both are
-invisible at runtime:
+before writing any.** Two of those four are worth repeating here, because both
+are invisible at runtime:
 
 1. A clause naming only one member of a `canonicalParamId` pair drops the sentence
    for every advanced-mode user. List all members:

.agents/skills/add-column-type/SKILL.md

@@ -148,13 +148,13 @@ Registering the *type* is compiler-enforced. Registering its *metadata* is not,
 - [ ] Icon added, centered on the family's optical center, exported alphabetically
 - [ ] `migrateCellsTo` / `migrateCellsFrom` added if the stored bytes change
 - [ ] New metadata keys added to `TYPE_SPECIFIC_COLUMN_KEYS` + `FOREIGN_METADATA_VERB`
-- [ ] Unit tests for `coerce` / `isCompatibleWith` round-trips, verified to fail without the code
+- [ ] Unit tests for `coerce` / `isCompatibleWith` round-trips only if they pass the `test-audit` authoring gate, verified to fail without the code
 - [ ] Docs row added to `apps/docs/content/docs/tables/index.mdx`
 
 ## Final Validation (Required)
 
 1. **`cd apps/sim && bun run type-check`** — must be clean. If any file *outside* `column-types/` errors, that file has a hardcoded type list; fix it to read the registry.
 2. **Grep for leaks** — `grep -rnE "(===|!==) '{id}'|case '{id}':" apps/sim --include='*.ts' --include='*.tsx' | grep -v column-types/`. (All three forms: a plain `!==` and a `case` are how half of `currency`'s real branches are written.) Hits are expected; judge each. A hit is fine when it mounts a specific React component or encodes a genuinely one-off behavior (`json`'s mono textarea, `date`'s timezone-aware parsing). A hit is a **leak** when it restates something the registry could answer — an icon, a label, a colour, an operator set, a cast, a coercion. Leaks get a registry field, not a new branch.
-3. **Run the suite** — `bunx vitest run lib/table 'app/workspace/[workspaceId]/tables' lib/api app/api/table app/api/v1 lib/copilot/tools/server/table`. Existing tests must pass **unchanged**; needing to edit one means you changed behavior for the other types.
-4. **`bun run lint:check`, `bun run check:api-validation`, `bun run check:client-boundary`** from the repo root.
+3. **Run the suite** — `bun run --cwd apps/sim test lib/table 'app/workspace/[workspaceId]/tables' lib/api app/api/table app/api/v1 lib/copilot/tools/server/table`. Existing tests must pass **unchanged**; needing to edit one means you changed behavior for the other types.
+4. **`bun run lint`, `bun run check:api-validation`, `bun run check:client-boundary`** from the repo root.
 5. **Exercise it in the running app** on a table with one column of every type: create, edit inline / in the expanded popover / in the row modal, paste from a spreadsheet, filter, sort, convert to and from other types, export CSV, undo a column delete.

.agents/skills/add-feature-flag/SKILL.md

@@ -83,9 +83,9 @@ Critically, **none of this is expressible in code** — gating (especially `admi
 
 4. **(Prod) configure in AppConfig.** The infra `feature-flags` profile schema is permissive, so a new flag needs **no infra change**. Operators add the flag to the hosted `feature-flags` document using `enabled` for global rollout or only the selected `workspaceIds`/`orgIds`/`userIds`/`adminEnabled` clauses for scoped rollout, then start a `sim-<env>-fast` deployment (see the AppConfig runbook in the infra README — same flow as `access-control`). The fallback secret only applies when AppConfig is disabled.
 
-5. **Test.** Add a case to `apps/sim/lib/core/config/feature-flags.test.ts` that matches the chosen granularity. For a global flag, exercise `isFeatureEnabled('<flag-name>')` with an AppConfig `enabled` rule and toggle the fallback secret for the off-AppConfig path. For scoped rollout, cover only the selected clauses and mock `isPlatformAdmin` when testing `adminEnabled`.
+5. **Test only new evaluation logic.** A flag that reuses the existing clauses is already covered by `apps/sim/lib/core/config/feature-flags.test.ts`; add no per-flag case. When you change how flags evaluate (a new clause kind, a new fallback path), add a case there that passes the `test-audit` authoring gate.
 
-6. **Clean up after rollout.** When the feature ships to everyone, delete the flag's entry from `FEATURE_FLAGS`, the `<FLAG_SECRET>` env entry, the AppConfig document, the call sites, and the test. Leaving dead flags around is the main failure mode of flag systems.
+6. **Clean up after rollout.** When the feature ships to everyone, delete the flag's entry from `FEATURE_FLAGS`, the `<FLAG_SECRET>` env entry, the AppConfig document, and the call sites. Leaving dead flags around is the main failure mode of flag systems.
 
 ## Notes
 

.agents/skills/add-managed-cli/SKILL.md

@@ -99,7 +99,7 @@ Do not special-case a CLI in those layers unless the registry contract cannot ex
 
 ## 6. Test the Addition
 
-Extend tests when the new entry introduces behavior not already covered:
+Extend tests only when the new entry introduces behavior not already covered and the test passes the `test-audit` authoring gate:
 
 - For every upgrade, add a regression proving the old ID and recipe remain resolvable but non-selectable, while the replacement ID is selectable.
 - Add important executable aliases to the table-driven search assertion.
@@ -110,17 +110,13 @@ Never commit downloaded artifacts or credentials.
 
 ## Required Validation
 
-From `apps/sim`:
-
 ```bash
-bunx vitest run \
+bun run --cwd apps/sim test \
   lib/execution/remote-sandbox/cli-tools.test.ts \
   lib/execution/remote-sandbox/cli-tools-boundary.test.ts \
   lib/execution/remote-sandbox/sandbox-spec.test.ts \
   lib/execution/remote-sandbox/resolve.test.ts \
-  lib/api/contracts/sandboxes.test.ts \
-  'app/workspace/[workspaceId]/settings/components/sandboxes/utils.test.ts' \
-  'app/workspace/[workspaceId]/settings/components/sandboxes/components/sandbox-editor.test.tsx'
+  'app/workspace/[workspaceId]/settings/components/sandboxes/utils.test.ts'
 ```
 
 From the repository root:

.agents/skills/add-permission-group-item/SKILL.md

@@ -210,7 +210,7 @@ bun run check:permission-group-enforcement
 bun run check:application-graph
 bun run check:capability-subject
 cd apps/sim && bun run type-check
-cd apps/sim && bunx vitest run lib/permission-groups
+bun run --cwd apps/sim test lib/permission-groups
 ```
 
 Also `bun run check:api-validation` if you touched a contract or the group routes. `bun run check:audits` runs all of these; it derives its list from the `check:*` scripts in `package.json`, so a new audit is opted *out* deliberately rather than opted in.

.agents/skills/add-selector/SKILL.md

@@ -122,7 +122,7 @@ list, manifest/registry exhaustiveness plus an existing provider primitive test
 Run the smallest relevant set, then:
 
 ```bash
-bunx vitest run <focused selector tests>
+bun run --cwd apps/sim test <focused selector tests>
 bun run --cwd apps/sim type-check
 bun run check:fork-dependent-coverage
 bun run check:client-boundary

.agents/skills/add-tools/SKILL.md

@@ -256,7 +256,7 @@ Hard rules:
   provider responses, filenames, URLs, and errors remain unchanged when Sim did not resolve a
   secret into them.
 
-Add focused tests covering named projection, ordinary identical text without provenance, nested and
+Run the `test-audit` authoring gate, then cover these risks at the boundary that owns them: named projection, ordinary identical text without provenance, nested and
 serialized shape handling, unchanged ordinary external inputs, malformed/incomplete private metadata
 failing closed, headerless legacy requests, and absence of private metadata in the public tool result.
 For durable sinks, also cover legacy `NULL` markers, exact-empty new writes, tracked secret writes,

.agents/skills/babysit/SKILL.md

@@ -121,15 +121,13 @@ conditions freshly after every push.
    ```
 
 6. **Before pushing, re-run the full sync check from `/ship` step 2** — not just the log command,
-   the whole check-and-recover flow (stash WIP if needed, rebase, verify the rebase didn't just
+   the whole check-and-recover flow (stash WIP pinned by SHA as `/ship` step 2 shows, rebase, verify the rebase didn't just
    cleanly replay stray commits, cherry-pick rebuild if it did or if it conflicted). A babysit
    loop spanning a long session is exactly the scenario where a branch can drift, and pushing
    review fixes on top of undetected drift is how an oversized PR happens even after the branch
-   was fixed once. Then run the repo's pre-ship checks the same way `/ship` does before
-   committing — not just lint/typecheck/boundary-validation, but also the conditional `/cleanup`
-   (if this round's fix touched UI code) and `/db-migrate` (if it touched schema/migrations)
-   gates from `/ship` steps 4 and 5. A review-fix round is still a code change and can trip
-   either gate just as easily as the original commit did.
+   was fixed once. Then run `/ship` steps 4–6 on this round's diff — the cleanup and test gates,
+   migration safety, and the regenerate + audit phases. A review-fix round is still a code change
+   and can trip any of them just as easily as the original commit did.
 
 7. **Commit and push** the round's fixes as one commit — `--force-with-lease` whenever step 6's
    sync check rewrote history, which includes a plain `git rebase origin/staging` that completed

.agents/skills/cleanup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cleanup
-description: Run all code quality skills — effects, memo, callbacks, state, React Query, emcn design review, url-state, and comments — analyzing in parallel, then applying fixes sequentially
+description: Run all code quality skills — effects, memo, callbacks, state, React Query, emcn design review, url-state, comments, and test-audit — analyzing in parallel, then applying fixes sequentially
 argument-hint: "[scope] [fix=true|false]"
 ---
 
@@ -16,9 +16,9 @@ User arguments: $ARGUMENTS
 
 Parse `$ARGUMENTS` into `scope` and `fix`: extract the `fix=true|false` token wherever it appears in the string and strip it from `scope`; defaults are the current changes and `fix=true`. `fix` is consumed by Step 3 only — the passes below always run `fix=false`.
 
-Spawn all eight passes concurrently as subagents in a **single message** (multiple Agent tool calls). Each runs its skill on the parsed `scope` with `fix=false` — analysis and proposals ONLY, no edits. Instruct each agent to return its findings as a structured list: for every proposed change, the file path, line range, a one-line description of the change, and the exact before/after so the orchestrator can apply it without re-deriving.
+Spawn up to nine passes concurrently as subagents in a **single message** (multiple Agent tool calls); pass 9 runs only when its condition holds. Each runs its skill on the parsed `scope` with `fix=false` — analysis and proposals ONLY, no edits. Instruct each agent to return its findings as a structured list: for every proposed change, the file path, line range, a one-line description of the change, and the exact before/after so the orchestrator can apply it without re-deriving.
 
-Run these eight in parallel on the parsed `scope`:
+Run these in parallel on the parsed `scope`:
 
 1. `/you-might-not-need-an-effect <scope> fix=false`
 2. `/you-might-not-need-a-memo <scope> fix=false`
@@ -28,35 +28,36 @@ Run these eight in parallel on the parsed `scope`:
 6. `/emcn-design-review <scope> fix=false`
 7. `/you-might-not-need-url-state <scope> fix=false`
 8. `/you-might-not-need-a-comment <scope> fix=false`
+9. `/test-audit audit <test paths>` — read-only; only when the scope adds or changes test files (`*.test.ts(x)`, `*.integration.ts`, `**/e2e/**`, `apps/sim/scripts/test-*-e2e.ts`). First resolve a free-form scope to the concrete list of added or changed test paths (`git diff --name-only` against the scope's base) and pass those paths. It applies the authoring gate to every new or changed test and proposes deleting the ones that fail it.
 
 ## Step 2 — Converge
 
-Collect all findings into one list, **keeping each proposal tagged with the pass that produced it** — do NOT collapse a file's proposals into a single unlabeled patch, because Step 3 applies in pass order and needs those labels. Detect overlaps where two passes touch the same region (common: a state pass and an effect pass on the same block, or a memo and callback pass on the same component). Reconcile only genuine same-region conflicts, and drop proposals a sibling pass has made moot; a reconciled change inherits the pass label of whichever of its passes comes first in the Step 3 dependency order (effects → state → memo → callback → React Query → url-state → emcn → comments), so it is applied at the earliest safe point. Non-overlapping proposals stay as-is with their own labels. The output is a per-pass list of surviving changes, not a per-file patch.
+Collect all findings into one list, **keeping each proposal tagged with the pass that produced it** — do NOT collapse a file's proposals into a single unlabeled patch, because Step 3 applies in pass order and needs those labels. Detect overlaps where two passes touch the same region (common: a state pass and an effect pass on the same block, or a memo and callback pass on the same component). Reconcile only genuine same-region conflicts, and drop proposals a sibling pass has made moot; a reconciled change inherits the pass label of whichever of its passes comes first in the Step 3 dependency order (effects → state → memo → callback → React Query → url-state → emcn → comments → tests), so it is applied at the earliest safe point. Non-overlapping proposals stay as-is with their own labels. The output is a per-pass list of surviving changes, not a per-file patch.
 
 ## Step 3 — Sequential apply
 
 If `fix=false`, skip this step — just report the proposals from Step 2.
 
 Otherwise apply the surviving changes yourself (in the main context, not delegated), iterating **pass by pass** in this dependency order so earlier structural changes settle before later passes build on them:
 
-1. effects → 2. state → 3. memo → 4. callback → 5. React Query → 6. url-state → 7. emcn design → 8. comments
+1. effects → 2. state → 3. memo → 4. callback → 5. React Query → 6. url-state → 7. emcn design → 8. comments → 9. tests
 
 For each pass in turn, apply all of that pass's changes, then move to the next pass. A file touched by several passes is therefore edited once per pass, in this order — not once as a merged patch. This is what makes the ordering real: a single merged-per-file patch would collapse all passes into one edit and lose it.
 
-Comments apply last, on purpose: that pass operates on whatever the earlier structural passes settled the code into, so it never edits lines a sibling pass is about to delete or rewrite.
+Comments apply after every structural pass, on purpose: that pass operates on whatever the earlier passes settled the code into, so it never edits lines a sibling pass is about to delete or rewrite. Tests apply last because they only touch test files; in Step 2, drop any other pass's proposal on a test file the tests pass deletes.
 
 **Treat every Step 1 proposal as snapshot-relative, not authoritative.** All passes analyzed the *original* files in parallel, so a proposal's line ranges and before/after text describe the code as it was *before* any edits — once an earlier pass has run, a later pass's snippet may no longer match. So for each change, before applying:
 
 1. Re-read the file and locate the target by its **content** (the proposal's `old_string` snippet), not by its line number — line numbers from Step 1 are only a hint for where to look, since earlier edits shift them.
 2. If the `old_string` still matches verbatim, apply it — a content-anchored edit is safe even if its line moved.
 3. If it no longer matches (an earlier pass altered that region), do **not** force the stale patch. Re-derive the change from the current code by re-applying that pass's rule to the construct, or drop it if a prior pass already made it moot. Never apply a proposal against text it wasn't computed from.
 
-After all edits, run `bun run lint:check` (it runs `turbo run lint:check` across the repo — there is no per-file target, so run the full check).
+After all edits, run `bun run lint` from the repo root (it autofixes formatting across the repo; there is no per-file target).
 
 ## Step 4 — Summary
 
-Output a summary across all eight passes: what each found, what was applied vs. skipped-as-redundant, and any proposals that need a human decision.
+Output a summary across all passes that ran: what each found, what was applied vs. skipped-as-redundant, and any proposals that need a human decision.
 
 ## Boundary findings
 
-Never resolve a boundary finding by adding a `// boundary-raw-fetch` / `// double-cast-allowed` annotation — fix the call (adopt the contract + `requestJson`, or narrow the type). Annotations are only for the documented exceptions in CLAUDE.md → Boundary annotations.
+Never resolve a boundary finding by adding a `// boundary-raw-fetch` / `// double-cast-allowed` annotation — fix the call (adopt the contract + `requestJson`, or narrow the type). Annotations are only for the documented exceptions in `.claude/rules/sim-api-contracts.md` → Boundary annotations.