Requirements
This document is JobCtrl's current software requirements catalog: the invariants that must stay true as the implementation changes. It is split into behavioral requirements (BR-*) — what the system should do for users — and technical requirements (TR-*) — the implementation constraints behind them. Each ID is a stable handle that is never reused, so code, PRs, and QA can cite a requirement by number.
Every requirement is one row in the tables below. The Added column is the date the requirement first appeared in this file's git history, not the date it was last edited; the Related docs column points at the current owning documentation, not the historical plan that first proposed it.
Behavioral Requirements
Product Safety
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| BR-001 | 2026-05-22 | JobCtrl must never submit applications, run destructive profile/database actions, or bypass third-party controls unless the user explicitly authorizes that behavior; this includes browser submission, CAPTCHA, paywall, login, rate-limit, and bot-control bypass. | Job seekers. | Keep automation safe, consent-driven, and compliant with site policies. | README, pipeline architecture |
| BR-050 | 2026-07-04 | JobCtrl must enforce a configurable daily LLM spend ceiling: every workflow that spends LLM tokens runs a budget preflight and stops with a non-retryable budget error once the day's estimated spend reaches the ceiling, and the over-budget state must be surfaced to the user. | Job seekers. | Prevent runaway LLM cost during automated runs. | pipeline operations, configuration |
| BR-054 | 2026-07-04 | Apply submission must be at-most-once: run claiming must exclude running, succeeded, and needs-verification runs; a submit-intent checkpoint must be recorded before the agent may submit; and a crash after submit intent must park the run for human verification instead of retrying. | Job seekers. | A duplicate application is worse than a missed retry. | stage walkthrough, security |
Operations And Workflow
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| BR-002 | 2026-05-22 | Every job must expose explicit durable state for discovery, enrichment, scoring, tailoring, cover-letter, PDF, and apply stages, including blocked, failed, skipped, exhausted, canceled, stale, and running states where applicable. | Job seekers and operators. | Show what happened, what is blocked, and what can be retried without reading the database. | pipeline architecture |
| BR-003 | 2026-05-22 | Failed retryable stages must be retryable without rerunning the entire pipeline, and retrying one stage must not silently reset unrelated stage progress. | Job seekers. | Recover from local failures without duplicating work or losing progress. | pipeline architecture, local reliability QA |
| BR-004 | 2026-05-22 | Workflow execution must record event history, run identifiers, workflow identifiers, and current status for user-triggered and automated work. | Job seekers and maintainers. | Make long-running work observable, cancellable where possible, and debuggable. | local TypeScript API, pipeline architecture |
| BR-005 | 2026-05-22 | Apply automation must expose clear status, logs, next action, retry options, dry-run state, and timeout failures per job. | Job seekers. | Make high-risk application steps inspectable before and after automation runs. | pipeline architecture, local reliability QA |
| BR-006 | 2026-05-22 | The web app must show dashboard, jobs, artifacts, profile, workflow-run, and apply-run views backed by the TypeScript API. | Job seekers operating their search. | Provide a usable local product instead of requiring command-line or database work. | frontend target, local TypeScript API |
| BR-007 | 2026-05-22 | The operations dashboard must show stuck, failed, blocked, ready, active, and applied work, plus recent activity and active runs. | Job seekers and operators. | Prioritize the next useful action during a job search. | local TypeScript API |
| BR-008 | 2026-05-22 | Job detail views must show stage state, event history, artifacts, score detail, apply status, and safe available actions. | Job seekers. | Let users understand and control each job from one place. | pipeline architecture, local TypeScript API |
| BR-009 | 2026-05-22 | Lists must support stable filtering, sorting, pagination, deep links, and drawer state while background work updates local data. | Job seekers reviewing many jobs. | Keep navigation predictable as local data changes. | frontend target, local TypeScript API |
| BR-010 | 2026-05-22 | UI actions must call structured API actions where backend support exists, returning accepted command state and run identifiers instead of relying only on copied shell commands. | Job seekers. | Provide real product controls for actions that the API owns. | local TypeScript API, pipeline architecture |
| BR-056 | 2026-07-05 | Browser-extension assisted autofill must use deterministic profile-backed suggestions that the user reviews and accepts, and the extension must not submit applications. | Job seekers filling ATS forms. | Speed up repetitive form entry without bypassing apply-safety controls or inventing answers. | README, local TypeScript API, local reliability QA |
Discovery And Enrichment
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| BR-011 | 2026-05-22 | Discovery must prioritize the user's configured target roles, locations, seniority, tracks, and work models. | Job seekers. | Focus results on the user's active search instead of broad generic scraping. | local TypeScript API |
| BR-012 | 2026-05-22 | Saved target-search locations must be validated as real places before they can drive discovery. | Job seekers configuring searches. | Prevent invalid searches from polluting results. | local TypeScript API, local reliability QA |
| BR-013 | 2026-05-22 | Hybrid and on-site discovery must filter exclusively for the configured target location. | Job seekers. | Keep location-bound results relevant to where the user can work. | local TypeScript API, local reliability QA |
| BR-014 | 2026-05-22 | Remote discovery must filter for the configured target country or region. | Job seekers. | Keep remote results aligned with the user's legal and practical work target. | local TypeScript API, local reliability QA |
| BR-015 | 2026-05-22 | Remote discovery for European target countries must also include jobs remote in Europe. | Job seekers. | Capture regional remote roles that are relevant even when not tied to one country. | local TypeScript API, local reliability QA |
| BR-016 | 2026-05-22 | Profile-driven target discovery must search at least the last 30 days unless local configuration sets a larger lookback window. | Job seekers. | Avoid stale searches while allowing broader local search windows when requested. | local TypeScript API |
| BR-017 | 2026-05-22 | Aggregators and broad boards may provide leads, but JobCtrl must prefer canonical employer, ATS, API, licensed feed, or official posting sources before downstream scoring and automation. | Job seekers. | Improve relevance, freshness, and applyability of jobs. | pipeline architecture |
| BR-018 | 2026-05-22 | Source quality must be observable and support trusted, normal, experimental, quarantined, and disabled states. | Job seekers and maintainers. | Stop low-quality sources from degrading the pipeline. | local reliability QA |
| BR-019 | 2026-05-22 | Manual capture must be available for useful leads that cannot be fetched safely, including user-provided URLs, saved HTML, pasted text, browser-extension active-page captures, or email-derived posting content. | Job seekers. | Allow user-mediated progress without bypassing third-party protections. | README, pipeline architecture, local reliability QA |
| BR-020 | 2026-05-22 | Discovery and enrichment must preserve provenance, source observations, canonical URLs, apply URLs, active state, full descriptions, snapshots, and source-native identifiers where available. | Job seekers and maintainers. | Make jobs auditable, deduplicable, and useful for scoring and materials. | pipeline architecture |
| BR-021 | 2026-05-22 | Deduplication must preserve source observations and avoid silently merging uncertain fuzzy matches; uncertain matches must be reviewed or quarantined. | Job seekers. | Reduce duplicate clutter without losing evidence or creating bad merges. | pipeline architecture |
| BR-042 | 2026-05-30 | Target search must be configured from the Discovery page, not general Preferences, and must expose normalized IC, management, and executive tracks plus the approved engineering seniority ladders. | Job seekers configuring searches. | Keep discovery-specific controls next to discovery operations and prevent ambiguous free-form track/seniority input. | README, local TypeScript API, pipeline architecture |
| BR-043 | 2026-05-30 | Discovery must move postings verified unavailable, expired, removed, or location-incompatible to a Closed list that remains inspectable but is excluded from active dashboards and worker queues. | Job seekers reviewing discovered jobs. | Keep stale postings from polluting active work while preserving evidence about why they disappeared. | README, local TypeScript API, pipeline architecture |
| BR-044 | 2026-05-30 | Pipeline progress text must describe whether a stage is running, complete, failed, or ready to run again without exposing prior-worker recovery implementation details as the primary user message. | Job seekers running local pipelines. | Make long-running discovery/apply work understandable and actionable from the Pipelines page. | local TypeScript API, pipeline architecture, local reliability QA |
| BR-051 | 2026-07-04 | Scheduled discovery must be off by default; enabling a recurring discovery schedule must be an explicit operator action. | Job seekers. | Background automation and its cost must never be a surprise. | pipeline operations |
Single Discovery Preparation Stage
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| BR-034 | 2026-05-27 | Discovery must be the single user-facing preparation stage for finding, enriching, scoring, and tailoring eligible jobs; scoring and tailoring may still appear in job detail, diagnostics, and maintenance actions, but not as Jobs-list substages. | Job seekers. | Keep the product workflow simple without flattening the internal domain model. | pipeline architecture |
| BR-035 | 2026-05-27 | Tailoring must run only for jobs whose latest persisted score, hard-blocker state, active state, and current score threshold make them eligible. | Job seekers. | Prevent irrelevant or blocked jobs from consuming tailoring work or producing misleading artifacts. | pipeline architecture, tailoring |
| BR-036 | 2026-05-27 | Scoring policy, algorithm, prompt, rubric, parser, and correction-derived anchor changes must be versioned and rollbackable; new Discovery work uses the current scoring policy while existing jobs keep their recorded scoring policy version until explicitly rescored. | Job seekers and maintainers. | Make scoring changes auditable and reversible without silently rewriting recorded decisions. | pipeline architecture |
| BR-037 | 2026-05-27 | Users must be able to rescore one job with the current scoring policy and rescore all active jobs whose latest score was not produced by the current scoring policy. | Job seekers. | Let users adopt policy changes deliberately at per-job or backlog scale. | local TypeScript API, pipeline architecture |
| BR-038 | 2026-05-27 | Score threshold changes must apply to all discovered jobs: lowering the threshold must enqueue missing tailoring work for newly eligible jobs, and raising the threshold must soft-suppress active tailored artifacts for newly ineligible jobs. | Job seekers. | Keep tailoring eligibility consistent with the user's live preference without rescoring jobs. | local reliability QA, pipeline architecture |
| BR-039 | 2026-05-27 | Tailoring prompt and configuration changes must be versioned and rollbackable; new tailoring work uses the current tailoring policy while existing artifacts keep their recorded tailoring policy version until explicitly re-tailored. | Job seekers and maintainers. | Make generated materials auditable and avoid silently replacing already reviewed artifacts. | pipeline architecture, tailoring |
| BR-040 | 2026-05-27 | Users must be able to re-tailor one job with the current tailoring policy and re-tailor all active eligible jobs whose latest active tailored artifact was not produced by the current tailoring policy. | Job seekers. | Let users adopt tailoring prompt/configuration changes deliberately at per-job or backlog scale. | local TypeScript API, tailoring |
| BR-041 | 2026-05-27 | Soft-suppressed tailored artifacts must be hidden from active artifact displays and downstream apply readiness while remaining preserved as audit artifacts unless the user explicitly deletes them. | Job seekers and maintainers. | Keep active workflow surfaces truthful without destroying generated evidence. | local reliability QA, pipeline architecture |
Scoring
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| BR-022 | 2026-05-22 | Scoring must be an applicant-side decision aid, not an autonomous hiring or application decision. | Job seekers. | Help users prioritize while preserving human judgment. | pipeline architecture |
| BR-023 | 2026-05-22 | Auto-apply must never be gated by score alone; hard blockers, missing materials, safety policy, and user approval requirements must still apply. | Job seekers. | Prevent high scores from overriding blockers, missing materials, or safety policy. | pipeline architecture |
| BR-024 | 2026-05-22 | Persisted fit scores must be deterministic outputs of a versioned scoring policy over structured evidence, including technical fit, experience/seniority fit, and role fit, plus a requirement-fit dimension resolved from employer-analysis requirement assessments when they are present. | Job seekers and maintainers. | Make scores comparable, explainable, and reproducible. | pipeline architecture |
| BR-025 | 2026-05-22 | LLM scoring calls may extract evidence, gaps, blockers, transferable signals, confidence, and rationale, but must not be the final scoring authority. | Job seekers. | Reduce unsupported model opinion in decisions that affect applications. | pipeline architecture |
| BR-026 | 2026-05-22 | Low confidence must mean review needed, not a disguised low score, and missing evidence must reduce confidence even when a model proposes high fit. | Job seekers. | Distinguish weak evidence from poor fit. | pipeline architecture |
| BR-027 | 2026-05-22 | User score corrections must immediately affect future scoring, become calibration anchors, and mark comparable uncorrected scores stale until the user explicitly rescores them. | Job seekers. | Let the system learn from explicit user judgment without silently rewriting history. | local TypeScript API |
| BR-028 | 2026-05-22 | Score details must expose fit, band, blockers, confidence, evidence, gaps, dimensions, policy version, stale state, and correction trace. | Job seekers. | Explain why a job is recommended, questionable, or blocked. | local TypeScript API, pipeline architecture |
Materials, Profile, And Artifacts
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| BR-029 | 2026-05-22 | Profile data, resume style, templates, generated materials, and artifacts must remain local by default. | Job seekers. | Preserve privacy for sensitive career material. | pipeline architecture, architecture |
| BR-030 | 2026-05-22 | Profile editing must preserve existing profile, resume style, resume template, and import behavior until stable replacements are implemented. | Job seekers. | Avoid losing user configuration during architecture changes. | local TypeScript API |
| BR-031 | 2026-05-22 | Cover letters must require tailored-resume prerequisites before generation. | Job seekers. | Prevent inconsistent or unsupported application material. | local reliability QA, pipeline architecture |
| BR-032 | 2026-05-22 | PDF generation must operate only on known DB-backed material artifacts unless product behavior intentionally expands that scope. | Job seekers. | Prevent accidental conversion of unrelated local files. | local reliability QA, pipeline architecture |
| BR-033 | 2026-05-22 | Artifacts must be visible, inspectable, previewable where supported, and openable only through known local artifact metadata. | Job seekers. | Make generated outputs useful while avoiding unsafe file access. | local TypeScript API, pipeline architecture, local reliability QA |
| BR-045 | 2026-05-30 | Editable profile, preferences, discovery-target, and general settings forms must autosave five seconds after the last edit and support Ctrl+Z/Cmd+Z undo for setting controls that do not have native text undo. | Job seekers editing local settings. | Prevent accidental loss of search configuration while keeping rapid checkbox/select changes reversible. | frontend target, local TypeScript API, local reliability QA |
| BR-046 | 2026-06-24 | Apply Review must render current HTML/CSS-generated resumes from the same generated HTML source that prints the final PDF, using a Plate-backed resume surface with line selection and JobCtrl audit annotations inside the resume instead of a side-by-side PDF/image overlay. | Job seekers reviewing tailored materials. | Let users inspect the final resume layout and audit comments in one faithful document surface before approval. | local TypeScript API, local reliability QA |
| BR-047 | 2026-06-24 | Approved LaTeX resume artifacts must remain inspectable and have a safe conversion or refresh path onto the HTML/CSS resume source when needed. | Job seekers with existing generated materials. | Preserve existing artifacts while keeping review and future editing on the same render source. | README, local reliability QA |
| BR-048 | 2026-06-26 | Resume template editing must let the user save style/layout templates, choose a default template, and override the template per job without persisting candidate profile data or job facts into the template payload. | Job seekers tailoring visual presentation. | Let users control resume appearance while preserving profile-data ownership and privacy. | local TypeScript API, frontend target, local reliability QA |
| BR-049 | 2026-06-30 | Resume tailoring must plan coverage from job requirements to existing profile achievements before writing, preserve pinned and requirement-covered content even when it exceeds the normal bullet budget, and expose bounded Apply Review audit summaries for coverage, gaps, claim labels, revision decisions, and review blockers without leaking raw prompts, full profile/job text, local paths, generated PDFs, logs, browser data, or SQLite contents. | Job seekers reviewing tailored materials. | Make generated resumes explainable and reviewable while keeping profile evidence and local artifacts private. | tailoring, local TypeScript API, local reliability QA |
| BR-052 | 2026-07-04 | Apply Review must support interactive resume revision — draft edits, named revisions, and comment threads — with draft-aware approval, and revising must never destroy the last accepted artifact. | Job seekers reviewing materials. | Let users correct materials safely before submission. | materials audit, local TypeScript API |
Technical Requirements
Product Surface And Runtime
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| TR-001 | 2026-05-22 | JobCtrl must use the TypeScript API, React web app, and Python automation engine as its supported product surface. | Users and maintainers. | Provide one clear supported architecture. | architecture, local TypeScript API |
| TR-002 | 2026-05-22 | Hosted, multi-tenant, billing, managed browser, managed workflow, and cloud-storage features must stay out of local mode until explicit scale or product triggers are met. | Maintainers and future hosted users. | Protect the local product from premature SaaS complexity. | architecture, DDD target, frontend target |
| TR-003 | 2026-05-22 | The local stack must run a Temporal dev server, TypeScript API, React/Vite web app, and Python worker through a documented developer command, with pnpm dev as the full attached stack entry point. | Users and contributors running the app locally. | Make the full product path reproducible without stitching services together manually. | README, package scripts |
| TR-004 | 2026-05-22 | The TypeScript API must expose typed local JSON endpoints for health, dashboard, jobs, artifacts, profile, settings, workflow runs, job events, event streaming, and actions. | The React app and local automation users. | Give the UI stable contracts instead of relying on SQLite inspection or shell output. | local TypeScript API, architecture |
| TR-005 | 2026-05-22 | The API must use local-only defaults, including the documented loopback API address, restrictive browser access, and token-gated browser-extension routes that cannot bypass the loopback Host gate. | Local users. | Avoid accidentally exposing private job-search data outside the machine. | local TypeScript API |
| TR-006 | 2026-05-22 | SQLite must remain the local source of truth until a hosted or scale trigger requires another database, and API, SSE, and worker activities must agree on the active database path. | Local users and maintainers. | Preserve a simple, inspectable, portable local data model. | architecture, local TypeScript API |
Architecture And State
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| TR-007 | 2026-05-22 | JobCtrl must model its domain through the Pipeline, Profile, Scoring, Materials, Discovery, Enrichment, Apply, and Operations contexts. | Maintainers. | Keep product behavior organized around stable domain boundaries. | DDD target, architecture |
| TR-008 | 2026-05-22 | Temporal must orchestrate local long-running work: JobPipelineWorkflow for batch stage runs, DiscoverWorkflow for discovery, JobPreparationWorkflow for per-job preparation, ApplyWorkflow for apply automation, and ProfileImportWorkflow / CompensationRefreshWorkflow for heavy maintenance commands. | Job seekers running local automation. | Provide durable workflow execution and cancellation for work that can outlive a single request. | pipeline architecture, architecture |
| TR-009 | 2026-05-22 | JobCtrl must publish local domain events to projection-backed read models with resumable projection state. | The API, UI, and maintainers. | Keep operational views accurate without coupling them to write internals. | architecture, frontend target |
| TR-010 | 2026-05-22 | The web app must receive local event updates through the API's GET /v1/events/stream SSE stream. | Job seekers monitoring active work. | Reflect worker progress without disruptive full-page refreshes. | frontend target, local TypeScript API |
| TR-011 | 2026-05-22 | Realtime updates must preserve list context such as filters, selection, scroll position, and loading state where practical, using targeted updates where available and invalidation otherwise. | Job seekers reviewing and triaging jobs. | Prevent background workflow progress from interrupting active review. | frontend target, local TypeScript API |
| TR-012 | 2026-05-22 | The frontend must keep server state, URL state, and client-only state separate through TanStack Query, TanStack Router, and client-state stores or context. | Maintainers and users. | Avoid stale UI behavior and make workflows shareable or restorable through URLs. | frontend target, decisions |
| TR-029 | 2026-05-30 | Settings autosave and undo must reuse the existing TanStack Form validation and mutation paths, debounce saves for five seconds after edits, clear pending saves on reset/unmount, and keep an in-session bounded undo history for non-text setting controls. | Maintainers and users. | Preserve one source of validation/persistence behavior while making settings edits resilient. | frontend target, local TypeScript API, local reliability QA |
| BR-053 | 2026-07-04 | A local backup command must produce a consistent copy of the SQLite database, and schema migrations must be guarded by a schema-version check. | Job seekers and maintainers. | Protect local data across upgrades and mistakes. | storage, README |
| TR-033 | 2026-07-04 | The TypeScript API and the Python worker must communicate over the local JSON-RPC protocol at the internal RPC route, and worker-backed API actions must be gated on a healthy worker heartbeat. | Maintainers. | Keep the TS↔Python boundary explicit, typed, and observable. | local TypeScript API, runtime boundaries |
Preparation Orchestration
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| TR-022 | 2026-05-27 | The integrated Discovery preparation workflow must remain event-driven through domain events, projection-backed read models, and idempotent preparation work items rather than UI-driven chaining. | Maintainers. | Keep long-running preparation restartable, observable, and decoupled across bounded contexts. | architecture, pipeline architecture |
| TR-023 | 2026-05-27 | Score, tailor, and artifact-suppression work selection must use indexed pending/outdated work queues or equivalent bounded selectors, not repeated unbounded full-table scans. | Maintainers and future hosted users. | Let the local SQLite design scale to larger job backlogs and map cleanly to a hosted queue later. | DDD target, pipeline architecture |
| TR-024 | 2026-05-27 | Every score and active tailored artifact must persist the scoring policy or tailoring policy version that produced it. | Maintainers and job seekers. | Make version drift, rollback, and explicit recomputation decisions inspectable. | local TypeScript API, pipeline architecture |
| TR-025 | 2026-05-27 | Score-threshold changes must recompute tailoring eligibility from persisted score and blocker data without invoking the scoring LLM. | Maintainers and job seekers. | Apply threshold changes quickly and cheaply without changing score history. | local reliability QA, pipeline architecture |
| TR-026 | 2026-05-27 | The API must expose structured per-job and bulk actions for current-version rescore and current-version re-tailor, returning accepted command state and run identifiers. | The React app and local automation users. | Provide safe product controls for deliberate recomputation instead of shell-only instructions. | local TypeScript API, pipeline architecture |
| TR-027 | 2026-05-27 | SSE invalidation must cover preparation work-item lifecycle events, scoring policy changes, tailoring policy changes, score-threshold eligibility changes, re-tailor requests, and artifact suppression. | Job seekers monitoring active work. | Keep lists, detail drawers, dashboards, and artifact views accurate during background preparation work. | frontend target, pipeline architecture |
| TR-028 | 2026-05-27 | QA coverage must include integrated Discovery preparation, policy-version roll-forward and rollback, threshold lowering and raising, soft artifact suppression, and per-job plus bulk rescore/re-tailor product flows. | Maintainers and job seekers. | Prevent regressions in the workflows most likely to waste LLM spend or show stale materials. | local reliability QA |
Materials Rendering
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| TR-030 | 2026-06-24 | The resume PDF renderer must be HTML/CSS printed by Playwright, while still producing the existing resume_pdf artifact type with RenderFormat.HTML_PDF; historical latex_pdf rows are read/migration compatibility only and must not invoke a TeX engine for new renders. | Maintainers and local users. | Keep downstream apply readiness and artifact compatibility while using the HTML/CSS renderer. | architecture, DDD target |
| TR-031 | 2026-06-24 | HTML-rendered resume artifacts must persist a generated sibling HTML file and generation-time layout boxes; the API must expose /preview.html only for supported html_pdf resume artifacts and project layout boxes into Apply Review materials preview data. | The API, web app, and maintainers. | Keep the final PDF, review surface, and line-level audit anchors tied to one generated render source. | local TypeScript API, local reliability QA |
| TR-032 | 2026-06-26 | Resume template changes must be applied lazily through an ensure-current-materials path when Apply Review or artifact open needs current resume materials; successful refresh writes a new render-only generation and unsuccessful refresh preserves the last accepted artifacts. | The API, web app, and maintainers. | Avoid eager regeneration work while keeping review/open flows current and auditable. | local TypeScript API, architecture, local reliability QA |
Security And Observability
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| TR-013 | 2026-05-22 | Credentials must use a secret port such as macOS Keychain or explicit environment variables, never SQLite, snapshots, logs, traces, or artifacts. | Job seekers. | Protect accounts used during local search and application workflows. | architecture |
| TR-014 | 2026-05-22 | Observability must cover LLM, workflow, and JSON-RPC activity without exporting raw private content such as resumes, generated materials, job text, credentials, local paths, logs, or databases. | Maintainers and local operators. | Debug behavior and cost while preserving user privacy. | architecture |
| TR-015 | 2026-05-22 | Langfuse and telemetry export must be configurable and disableable, including a local disable path for private runs. | Job seekers and maintainers. | Support local privacy choices and development diagnostics. | architecture |
| BR-055 | 2026-07-04 | A release privacy gate must scan tracked and untracked files, plus built distribution archives, for private-profile needles, secret assignments, forbidden filenames, and browser-profile artifacts on every push and pull request. | Maintainers and future users. | Keep personal data and secrets out of the public repository. | developer security |
Verification And Quality
| ID | Added | Requirement | For whom | Why | Related docs |
|---|---|---|---|---|---|
| TR-016 | 2026-05-22 | Missing frontend event handlers or stage badges must be caught by tests that cover the domain event union and stage-state kinds. | Maintainers. | Keep new domain states from silently rendering incorrectly. | frontend target, local reliability QA |
| TR-017 | 2026-05-22 | Scoring changes must be covered by evaluation fixtures and metrics for parsing, deterministic policy resolution, blockers, ranking, corrections, anchor consistency, stale-score precision, and reproducibility. | Maintainers. | Prevent prompt, policy, or parser changes from degrading decisions unnoticed. | local reliability QA |
| TR-018 | 2026-05-22 | Meaningful user-facing behavior changes must include product-path verification, not only unit tests. | Job seekers and maintainers. | Catch failures that only appear in real local workflows. | local reliability QA, frontend target |
| TR-019 | 2026-05-22 | High-risk local workflows must stay covered by the reliability matrix, including dry-run apply, apply timeout, retry, blocking, artifact opening, profile save/discard, source filtering, stale-score correction, and global list sorting. | Job seekers. | Prevent regressions in workflows that can waste time or corrupt local state. | local reliability QA |
| TR-020 | 2026-05-22 | Frontend accessibility defects found in production paths must be fixed or recorded as explicit backlog deferrals with production references. | Job seekers using assistive technology. | Keep the local UI usable and prevent silent a11y regressions. | local reliability QA, backlog |
| TR-021 | 2026-05-22 | Root scripts must expose the documented web test, type-level test, coverage, watch, Playwright, and extension verification commands: web:test, web:test:watch, web:test:coverage, web:test-d, web:e2e, web:e2e:headed, extension:check, extension:test, extension:build, and extension:e2e. | Contributors. | Make verification discoverable and consistent from the repo root. | package scripts |