@repo-os/repoos 0.5.45

package/dist/commands/check.d.ts

@@ -0,0 +1,170 @@
+import type { CheckContrastPair, CheckThemeScope } from "../core/types.js";
+/**
+ * Bare `require(...)` calls guard (#0271 follow-up): this package is
+ * `"type": "module"` (ESM) — a bare, un-shadowed `require` is undefined at
+ * runtime in the compiled `dist/` output, throwing `ReferenceError`.
+ * Confirmed live: `integration-job.ts`'s `removeJob()` used bare
+ * `require("fs")` inside a try/catch that silently swallowed the
+ * `ReferenceError`, so a moot close-out job was never actually deleted from
+ * disk — it kept getting re-picked-up and re-processed in a tight infinite
+ * loop, live, in production (task #0258), until someone noticed and asked
+ * why it was stuck.
+ *
+ * vitest transpiles TypeScript on the fly with its own module loader, which
+ * DOES provide a working `require()` even in these ESM-flagged files — so
+ * this bug is invisible to every unit test that imports the affected module,
+ * no matter how thorough. Only the actual compiled `dist/` output, run under
+ * Node's real ESM semantics, exposes it. This static, textual guard is the
+ * only check in the whole gate that runs against the real failure mode.
+ *
+ * `createRequire(...)` (a real, valid way to get a working `require` in ESM
+ * — see `ui-harness.ts`) shadows the global; a file that uses it anywhere is
+ * exempted file-wide rather than precisely scoping which calls are shadowed
+ * and which aren't — simpler, and a false negative here just means a
+ * legitimately-shadowed file's OTHER bare-require bugs (if any) go
+ * uncaught, never that a broken bare require ships silently.
+ */
+export declare function bareRequireOffenders(roots: string[], opts?: {
+    repoRoot?: string;
+    excludes?: string[];
+}): string[];
+/** Parse a `tsconfig.json` (JSONC) and read the fields the guard needs, or null. */
+export declare function readTsconfig(repoRoot: string): {
+    include?: unknown;
+    files?: unknown;
+    exclude?: unknown;
+} | null;
+export interface ResolvedBareRequireRoots {
+    /** Repo-relative source roots to scan; empty when nothing could be resolved. */
+    roots: string[];
+    /**
+     * Repo-relative globs/paths to skip — from `[check] bareRequireExcludes`, or
+     * the tsconfig's own `exclude` when the roots came from there.
+     */
+    excludes: string[];
+    /** Where the roots came from, for the check's status message. */
+    source: "config" | "tsconfig" | "none";
+}
+/**
+ * Decide which source roots the bare-`require()` guard scans (#0352). Explicit
+ * `[check] bareRequireDirs` wins; otherwise the repo's tsconfig `include` (plus
+ * `files`) is mapped to directories, minus its `exclude` list. Pure so the
+ * resolution is unit-testable; if neither yields a root the guard skips rather
+ * than passing vacuously.
+ */
+export declare function resolveBareRequireRoots(configured: string[] | undefined, tsconfig: {
+    include?: unknown;
+    files?: unknown;
+    exclude?: unknown;
+} | null, configuredExcludes?: string[]): ResolvedBareRequireRoots;
+/**
+ * Binary attachments (screenshots, PDFs) under the task/input folders must
+ * never enter git history: they are uploaded through the UI, written to
+ * `<dir>/.attachments/`, and served back by the running server from disk — the
+ * committed record is the task/input `.md`, not the pixels. Binaries in
+ * history bloat the repo irreversibly (this repo once carried ~250 MiB of
+ * stale screenshot churn). Product image assets — UI, icons, logos, docs —
+ * live outside those folders and stay tracked.
+ *
+ * The folder names come from `repoos.toml` (`workDir`/`inputsDir`) so a managed
+ * repo that renames them still gets the guard; they default to `work`/`inputs`.
+ *
+ * Pure (takes the tracked-file list) so it is unit-testable; the check block
+ * feeds it `git ls-files`.
+ */
+/**
+ * Normalize a configured guard directory (`workDir`/`inputsDir`) for prefix
+ * matching against `git ls-files` output, which is always repo-root-relative:
+ * strip any leading `./` and trailing slashes. Returns empty for anything that
+ * can't be a repo-relative directory — an explicit `""`, `"."`/`"./"`, an
+ * absolute path, a home-relative `~/…`, or a path containing a `..` segment.
+ * Those would all silently match nothing (or, for `""`, fatal git's pathspec),
+ * so callers must treat empty as unusable rather than as "match everything".
+ */
+export declare function normalizeGuardDir(d: string): string;
+export declare function taskAssetOffenders(trackedPaths: string[], dirs?: {
+    workDir?: string;
+    inputsDir?: string;
+}): string[];
+/**
+ * Scan a stylesheet for UNLAYERED universal/bare-element selectors.
+ * With Tailwind v4 everything lives in cascade layers; an unlayered `*`
+ * or tag rule silently beats every utility (unlayered > @layer), which
+ * already collapsed all shadcn padding once. Scoped class/ID/attribute
+ * rules are intentional legacy overrides and stay allowed.
+ */
+export declare function cssLayeringOffenders(css: string): string[];
+/** The `[check]` token vocabulary the theme-contrast guard evaluates. */
+export interface ThemeContrastConfig {
+    scopes: CheckThemeScope[];
+    pairs: CheckContrastPair[];
+    gradientTokens: string[];
+    /** Token to composite semi-transparent colors over; see CheckConfig. */
+    backdropToken?: string;
+}
+/**
+ * True when at least one configured scope selector opens a block in `css`.
+ * The theme-contrast step uses this to skip a stylesheet with no theme blocks
+ * rather than keying off a hardcoded RepoOS selector like `:root`.
+ */
+export declare function hasThemeBlocks(css: string, scopes: CheckThemeScope[]): boolean;
+/**
+ * Advisory config-shape warnings for declared theme scopes: a typo'd
+ * `inherits` target or a duplicated selector/name otherwise collapses
+ * silently (empty declarations / last-wins). Returned rather than thrown so
+ * `repoos check` can surface them without failing the gate on a config typo.
+ */
+export declare function themeScopeConfigWarnings(scopes: CheckThemeScope[]): string[];
+export declare function themeContrastOffenders(css: string, config: ThemeContrastConfig): string[];
+/**
+ * Which git ref (if any) to scope the Tests step to, via Vitest's own
+ * `--changed <ref>` (git-diff + module graph, only runs tests that could
+ * actually be affected). Unset for a standalone `repoos check` — that path
+ * is the full definition-of-done gate and must never narrow coverage.
+ *
+ * Only the two per-branch pre-merge checks set this: the engineer's own
+ * self-check before requesting handoff, and the server's handoff-finalize
+ * re-verification (both re-checking the SAME isolated branch, just diffed
+ * against its own base). The close-out gate that validates the actual merge
+ * onto main (integration-orchestrator.ts's validateCandidate) deliberately
+ * never sets it — that check is about interaction with whatever else has
+ * landed on main since, which a per-branch diff can't see.
+ */
+export declare function changedTestRef(env: NodeJS.ProcessEnv): string | undefined;
+/**
+ * The `package.json` script name a project uses to opt into `repoos check`'s
+ * UI smoke step with no configuration — the same zero-config convention
+ * `build`/`test`/`lint` already follow elsewhere in this gate.
+ */
+export declare const UI_SMOKE_SCRIPT = "smoke";
+export type SmokeCommand = {
+    source: "config";
+    command: string;
+} | {
+    source: "script";
+    script: string;
+};
+/**
+ * Resolve which UI smoke command (if any) `repoos check` should run for the
+ * current project (#0348). Precedence: `repoos.toml` `[check] uiSmoke` wins,
+ * then a `smoke` package.json script, else null — the caller then skips the
+ * step cleanly. RepoOS's own repo resolves through this same path (its `smoke`
+ * script); there is no RepoOS-only fallback.
+ */
+export declare function resolveSmokeCommand(configured: string | undefined, pkgScripts: Record<string, string> | undefined): SmokeCommand | null;
+/**
+ * Vitest worker-pool size for the Tests step. `vite.config.ts` pins a
+ * conservative floor (`maxWorkers: 2`) because several agent-driven check runs
+ * routinely overlap across worktrees and each pool otherwise multiplies against
+ * the others. But a solo run on an idle machine with memory to spare leaves
+ * most of the box idle — the subprocess-heavy suites (agent-review,
+ * done-reliability, task-watchdog) are I/O-bound on `waitFor` polls, so more
+ * workers is close to linear there.
+ *
+ * Scale up only with real headroom, gated on BOTH cpu count and reclaimable
+ * memory (budget ~900MB per worker + its fixture subprocesses). An explicit
+ * `REPOOS_TEST_WORKERS` always wins; anything else falls back to the config
+ * floor via `undefined`.
+ */
+export declare function testPoolSize(env: NodeJS.ProcessEnv): number | undefined;
+export declare function cmdCheck(): Promise<void>;