CareerVector Efficiency Stories

This catalog covers cost, quota, latency, and operational efficiency. User stories say what the user can accomplish. System stories say what platform guarantees make that possible. Efficiency stories say the same product remains cheap, fast, and predictable enough to operate.

The default rule is simple: zero budget unless a run explicitly opts in to spend budget.

Boundary with other story docs

Story type	Owns	Does not own
User stories	Applicant, collaborator, and agent-visible outcomes	Test bucket policy, cleanup mechanics, quota posture
System stories	Reliability, safety, orchestration, synthetic workspace lifecycle	Budget ceilings and runtime economics
Efficiency stories	Cost ceilings, provider spend controls, speed expectations, release-gate economics	Duplicating user journeys

Efficiency stories are still product stories. They exist because a feature that only works by spending uncontrolled provider budget is not acceptable product behavior.

Current testing taxonomy as efficiency policy

Bucket	Efficiency promise	Spend policy
`free-fast`	Tight feedback loop; should be cheap enough to run constantly	Zero budget; no live paid providers
`free-slow`	More complete proof while still free to repeat	Zero budget; local emulation, fixtures, and mocks only
`browser-smoke`	Real browser confidence without real provider spend	Zero budget; mock network and deterministic fixtures
`release-gate`	Release confidence assembled from free evidence first	Zero budget by default; paid/live work must be separately requested
`paid-forbidden`	Guardrail proving default paths do not spend money	Must fail on accidental paid-provider or quota-sensitive calls

The taxonomy is provider-neutral. "Paid" means any external path that can spend money, burn scarce quota, mutate a live account, or depend on a private vendor state. The exact provider is not part of the story contract.

Stories

Efficiency story E1: Default quality run spends no budget

Given a developer, release process, or quality service starts a default test run, when no explicit paid opt-in is supplied, then only free-fast, free-slow, browser-smoke, release-gate, and paid-forbidden zero-budget checks may run.

Acceptance criteria:

No test requires a secret to pass in the default path.
Live LLM, scraping, paid API, and quota-sensitive calls are blocked or mocked.
A missing provider secret causes a skip or clear configuration failure only for explicitly opted-in paid tests, never for the default gate.
paid-forbidden detects accidental live paid-provider calls.

Efficiency story E2: Fast checks stay fast enough for local loops

Given a contributor is iterating on product behavior, when they run free-fast, then the suite should finish quickly enough to be used repeatedly during normal development.

Acceptance criteria:

free-fast prefers pure functions, schemas, deterministic fixtures, and local operation contracts.
Browser startup, worker emulation, network calls, and large generated artifacts are excluded unless they are the behavior under test.
Failures point to product invariants, not incidental provider output.

Efficiency story E3: Slow free checks stay repeatable

Given a change touches persistence, browser behavior, worker behavior, or convergence, when free-slow runs, then it may take longer but must still avoid external spend and nondeterministic provider state.

Acceptance criteria:

Local emulation and deterministic fixtures replace live services by default.
Synthetic workspaces are clearly marked and cleaned after the run.
Failures preserve enough evidence for reproduction without retaining secrets.

Efficiency story E4: Browser smoke proves the app without provider spend

Given a browser smoke check opens the product, when it exercises a critical path, then it must prove rendering and interaction while using synthetic data, mocked providers, or fixture-backed responses.

Acceptance criteria:

Browser checks do not require real user data.
Synthetic workspace origin is recorded for every created workspace.
Cleanup removes the workspace and browser-created artifacts after success or failure.
Smoke evidence identifies viewport, bucket, and route tested.

Efficiency story E5: Release gate starts from zero-budget evidence

Given a release candidate is being evaluated, when the release-gate bucket runs, then the gate must first assemble zero-budget evidence and must not silently upgrade into paid live-provider testing.

Acceptance criteria:

The default release gate can run with no provider secrets.
Paid or live-provider checks are separate, named, and reported as opt-in.
A skipped paid opt-in cannot be counted as a pass.
The gate reports which buckets ran and which were intentionally blocked by budget policy.

Efficiency story E6: Quality service rejects ambiguous spend

Given quality.careervector.corbet.ch receives a request, when that request could spend paid provider budget or scarce external quota, then the service must reject, skip, or require explicit opt-in rather than guessing intent.

Acceptance criteria:

The service treats zero budget as the default for every request.
Provider-neutral spend policy applies before provider-specific routing.
Request and result payloads contain no secrets.
Results show whether spend-sensitive work was blocked by policy.

Efficiency story E7: Synthetic test data has a cleanup cost budget

Given automated tests create synthetic workspaces, documents, process requests, or browser artifacts, when the run completes or expires, then cleanup must be cheap, bounded, and targeted by origin metadata.

Acceptance criteria:

Cleanup queries use synthetic origin fields, not broad scans of real user data.
Cleanup is idempotent.
Cleanup can run after partial failures.
Cleanup reports remaining artifacts if deletion is incomplete.