# Test Integrity Notes ## 2026-09-30 — Exact observed-file ownership evidence ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-architect-file-ownership given: A committed project with a README, package manifest and JSON schema when: The Architect assigns observed files or invents absent files and directory globs then: Observed-file claims validate, invented claims fail, and oversized exact evidence reports truncation observable_outcomes: - Public pending-proposal validity, invented-path and unknown-evidence diagnostics - Exact evidence capped at 1000 files with explicit OWNERSHIP_EVIDENCE_TRUNCATED finding determinism_controls: - Disposable local Git history and fixed generated filenames - No provider calls, timers, network, retries or sleeps anti_cheat_rationale: prevents: - Assigning arbitrary unseen paths merely because metadata is not a source component - Leaving schemas and manifests permanently unassignable despite observed evidence - Claiming whole-repository ownership coverage from a truncated inventory relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Specialist-only project bootstrap ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-bootstrap-specialist-only given: Disposable test-only, release-only, combined and empty repositories when: Repository analysis generates an initial pending roster then: Evidenced QA/release roles have no conflicting catch-all owner and only empty evidence receives Core fallback observable_outcomes: - Exact generated domain IDs and successful approved-proposal validation - Git working tree remains unchanged after analysis and validation determinism_controls: - Real disposable committed Git histories and local fixtures - No provider calls, timers, external network, retries or sleeps anti_cheat_rationale: prevents: - Proposing a default owner that overlaps every subsequently added specialist - Suppressing real QA or release roles to avoid ownership rejection - Removing the fallback needed for an empty initial project relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` The new scenario first reproduced Core plus QA on a test-only repository. Production now adds the fallback after evidenced horizontal specialists, not before them. No previous assertion or collision guard was weakened. ## 2026-09-30 — Bootstrap primary ownership collisions ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-bootstrap-primary-ownership given: Two independently evidenced implementation domains in a disposable Git repository when: Pending or approved proposals duplicate primary paths or claim a recursive parent of another owner then: Validation rejects collisions while shared consultation and disjoint primary ownership remain valid observable_outcomes: - Pending validator problems and approved-install rejection with PROPOSAL_NOT_APPROVED - Recursive planned ownership conflicts rejected even before files exist - Backslash-normalized duplicate ownership rejected - Repository status remains unchanged determinism_controls: - Disposable committed Git repository with two source files per domain - No provider calls, external network, timers, retries or sleeps anti_cheat_rationale: prevents: - Accepting two implementation owners because their prose claims different outcomes - Treating a collision coordination note as authorization for duplicate ownership - Rejecting legitimate shared consultative access - Checking only existing files and ignoring planned recursive collisions relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` The first new fixture used one file per component; baseline design deliberately does not create a specialist for every one-file directory. The fixture now has two real files per domain, matching its stated precondition. No existing tests or expected ownership behavior changed. The check proves exact and literal recursive-parent conflicts, not arbitrary glob-language intersection. ## 2026-09-30 — Real Chromium surviving runner interruption ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-browser-descendant-interruption given: Real Chromium serves captured inputs through an actual prepared measurement subprocess when: Only the disposable TORCH runner dies, then the owned harness is explicitly stopped then: Browser initially remains usable, recovery without stopped-executor confirmation is refused, captured process-group terminal events precede abandonment observable_outcomes: - Real browser DOM, captured commit and visibility after runner exit - Pre-opened kernel handles for multiple Chromium group members and the owned harness - Terminal group check, no receipts, unchanged resource lease and original build retention determinism_controls: - Isolated test-owned Linux browser group with PID birth identity validation - HTTP readiness and pidfd events, no sleep or retry loops - Handles opened before shutdown avoid PID disappearance or reuse races - Qualification requires explicit browser and interruption flags anti_cheat_rationale: prevents: - Equating runner termination with browser termination - Treating a stopped-runner preview as automatic all-executor proof - Waiting on or signalling unrelated browser processes - Generating a pass or releasing leases through abandonment - Proving only a fake browser or a single process with no descendants relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Dashboard abandoned-check cleanup evidence ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-console-abandoned-check-cleanup given: Project-scoped pending, completed and malformed legacy recovery metadata when: Read-only snapshot and shared dashboard renderer observe it then: Cleanup states remain distinct, abandoned checks remain visible and private evidence is omitted - id: SCN-hard-killed-prepared-check given: Owned interrupted check with failed then replayed cleanup when: CheckService reopens after each outcome then: Pending and completed cleanup outcomes are durable and replay preserves one authority audit observable_outcomes: - Stored recovery metadata and unchanged read-only projection database - Escaped dashboard HTML, absent process IDs and private owner evidence - Real desktop/mobile Chromium demo with no live API requests or recovery buttons determinism_controls: - In-memory project-isolation/legacy database scenarios - Actual disposable interruption gated explicitly on Linux - Browser lifecycle controls and no sleep/retry masking anti_cheat_rationale: prevents: - Hiding abandoned work because it no longer has running state - Claiming cleanup complete from missing metadata - Leaking private process or input evidence through observations - Informational dashboard buttons performing automatic recovery - Losing cleanup outcomes after reopening relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Hard-interrupted check recovery and orphan receipts ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-hard-killed-prepared-check given: A real measurement subprocess blocked inside a disposable prepared check when: Test-owned runner and executor are terminated and the owner explicitly recovers then: Snapshot survives interruption, live recovery is rejected, abandonment is audited once and no receipt or lease release occurs - id: SCN-frozen-resource-check given: A passing frozen receipt whose prepared-operation linkage is interrupted when: Exact-pass qualification evaluates it then: Orphaned passing output cannot qualify until terminal linkage is restored observable_outcomes: - Runner and real measurement PID handshake, runner exit and pidfd terminal notification - Durable abandoned state, original recovery audit, exact-pass rejection and unchanged lease - Owner CLI approval refusal, idempotent replay and owned cleanup preservation determinism_controls: - Disposable projects with actual subprocesses, no live agents - Event-driven handshake and kernel pidfd wait, no timed sleeps or retries - Linux interruption qualification explicitly enabled; ordinary skips are not proof anti_cheat_rationale: prevents: - Treating a running database row or stale heartbeat as proof of process death - Inventing a pass from interrupted work or orphaned output - Deleting an unowned directory during cleanup - Automatic resource stealing or executor replay - Repeated recovery producing duplicate authority audit events relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` The hard-kill qualification uses Python's Linux pidfd API solely to terminate and await the exact disposable executor. This is a qualification dependency, not a TORCH runtime dependency. Normal portable kernel tests do not require it. ## 2026-09-30 — Owner-first scheduled stale-work review ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-manager-stale-work-review given: Owner and routine tasks, including blocked work, in a real managed Git fleet when: Manager previews or queues a bounded activity review then: Owner requests lead, task files remain unchanged, incomplete coverage is unknown and duplicate delivery is suppressed - id: SCN-scheduled-stale-work-review given: Approved daily local-time cron action with explicit stale-work bounds when: Schedule plans the due minute and executes with or without approval then: Only approved delivery queues one review, no runtime invokes and task state is preserved observable_outcomes: - Durable message body and kind, task file bytes and read-only MCP response - Actual schedule receipts, exact due-minute behavior and no provider calls - Output truncation, scoped task counts and blocked waiting context determinism_controls: - Disposable installed Git projects with real managed branches - Fixed task creation time and explicit local calendar time for cron - No host timers, network calls, retries or sleeps anti_cheat_rationale: prevents: - Prioritizing routine tasks above owner requests - Treating incomplete commit scans as proven inactivity - Automatically reopening blocked tasks or closing old tasks - Routine pending check-ins swallowing stale review delivery - Invoking AI or shell commands through an informational review relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` The new cadence test initially used a UTC timestamp despite existing host-local cron semantics, and read the check-in payload outside its existing `checkIn` receipt envelope. Fixture time/output addressing were corrected; strict minute, authority, deduplication and task-preservation assertions were retained. No pre-existing expectations were changed. ## 2026-09-30 — Same-runtime browser conditions and identity continuity ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-real-browser-conditions given: One persistent Chromium page with a frame-driven simulation clock when: Real subprocess probes surround healthy, frozen, drifting or replacement-runtime measurements then: Only healthy work gets an exact pass, preflight-frozen work is never measured and green invalid results remain incomplete - id: SCN-check-runtime-continuity given: Preflight reports a runtime identity when: Postflight loses or changes it, or preflight provides a malformed identity then: Green output cannot pass and malformed preflight never measures observable_outcomes: - Browser-generated runtime identity in probes and measurement output - Actual frame-driven clock movement, HTTP measurement counts and exact receipts - Retained invalid reasons and snapshot cleanup - Historical green flags do not bypass current report continuity validation determinism_controls: - Disposable projects and loopback-only persistent browser service - IPC readiness and frame completion without retries or sleeps - Explicit browser qualification opt-in; skipped scenarios are not proof anti_cheat_rationale: prevents: - Probing an independent healthy browser instead of the measured runtime - Claiming green command exit proves valid clock conditions - Accepting a replacement page with identical build and healthy conditions - Executing measurements after invalid preflight relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Real frozen browser and measurement subject identity ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-real-frozen-browser given: Captured ignored build queued behind a peer browser lease when: Specialist commits newer source and overwrites live output before promotion then: Real Chromium sees captured HTML and SHA, newer SHA receives no pass, new-build negative control fails - id: SCN-check-measurement-subject given: Checks with and without condition policies when: Actual child measurement commands inspect their subject environment then: Both receive the exact commit and input digest supplied to probes observable_outcomes: - Browser DOM, retained stdout, exact-SHA receipt lookup and snapshot cleanup - Actual child process output rather than a mocked executor determinism_controls: - Disposable Git repositories and loopback-only browser requests - Explicit resource lease release rather than timed waits - Browser frame completion awaited without sleeps or retries - Browser qualification explicitly enabled and never counted when skipped anti_cheat_rationale: prevents: - Passing by reading the live build instead of captured inputs - Unsafe hardlink capture surviving only atomic rebuilds - Crediting the newer source SHA with an old build pass - Echoing fixed success instead of browser-observed output - Supplying identity only to probes but not actual measurements relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Console owner-confirmed pilot conclusions ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-console-hierarchy-conclusion given: An activated pilot and same-origin Console access when: The owner previews and confirms reversal then: Fresh exact plans commit once while missing tokens, altered decisions, other operations, cross-site requests and changed main are rejected - id: SCN-console-hierarchy-adoption given: A completed pilot with supporting reviewer-reported evidence when: The owner separately confirms adoption through the Console API then: Adoption succeeds without changing the active graph or starting a runtime - id: SCN-hierarchy-pilot-review given: A stored completed review but current time precedes pilot maturity when: Adoption is planned then: The current calendar gate blocks adoption - id: SCN-dashboard-demo-browser given: The actual Console and an isolated qualitative pilot sample when: Adoption is previewed, then reversal is previewed and confirmed then: Adoption has no confirmation, reversal shows the scoped plan and changes sample state only observable_outcomes: - Blocked previews receive no confirmation token - Tokens bind target, operation, action and reason before replay handling - Existing stale-preview error contracts remain unchanged - Current-time maturity is rechecked at conclusion rather than inferred from stored flags - Browser demo preserves agents and backlog and contacts no live API - Candidate acceptance requires both adoption and reversal API evidence determinism_controls: - Disposable Git/SQLite fixtures and isolated loopback servers - Injected hierarchy calendar clocks with no sleeps - In-memory demo transport and Chromium anti_cheat_rationale: prevents: - Recommendations or preview requests changing organization state - Cross-operation replay bypassing an exact owner confirmation - Future-dated stored evidence bypassing present calendar maturity - A different mock dashboard substituting for actual controls relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Read-only pilot comparison dashboard ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-hierarchy-pilot-review given: Persisted interim and completed pilot reviews in a disposable project when: The Console snapshot reads hierarchy proposals then: Latest review comparisons and reviewer-reported provenance appear without changing history - id: SCN-dashboard-demo-browser given: The actual Console with a sample qualitative inconclusive pilot when: Its comparison history opens then: Baseline, observed value, units and evidence quality render as separate columns and no recommendation-execution button is offered observable_outcomes: - Snapshot exposes latest bounded review records with stable identifiers - Rendered recommendations explicitly do not change the organization - Reviewer-reported evidence is not presented as independently verified - Mobile page remains within its viewport and demo makes no live API requests determinism_controls: - Disposable Git/SQLite fixture and controlled review timestamps - In-memory sample transport and loopback Chromium browser anti_cheat_rationale: prevents: - Read-only dashboard observation modifying review records - A qualitative observation rendered as measured or independently verified - Source-text assertions substituting for rendered comparison behavior relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Owner-confirmed hierarchy conclusions ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-hierarchy-pilot-review given: An activated pilot with a complete supporting review when: An owner confirms adoption against a fresh plan hash then: The pilot is adopted without changing the graph, and unauthorized, unconfirmed or stale confirmations fail - id: SCN-hierarchy-pilot-reversal given: An activated pilot with actual worktrees, assigned backlog work and durable messages when: The owner previews and confirms reversal then: Prior relationships return at a new revision without changing implementation ownership, identities, worktrees, tasks, messages or schedules observable_outcomes: - CLI plan hashes agree with service plans and CLI requires explicit owner confirmation - An unrelated new commit invalidates an earlier plan - Failed Git commits restore tracked file bytes and the index - Injected audit failure rolls back local state but retains the tracked receipt - Repeated confirmation reconciles that receipt without committing again - Confirmed replays do not duplicate the owner audit - Candidate acceptance rejects absent pilot-reversal evidence determinism_controls: - Disposable Git/worktree and SQLite fixtures - Fixed clocks, failing Git hook and injected local audit trigger - No real provider or system timer calls anti_cheat_rationale: prevents: - Quietly dropping in-flight work while removing management roles - Reusing a stale owner plan after main moves - Repeating a committed conclusion after local state recording fails - Allowing review recommendations to bypass owner confirmation relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Durable hierarchy pilot comparisons ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-hierarchy-pilot-review given: An owner-activated hierarchy pilot with baseline metrics and success/stop criteria when: Session Manager records interim and final review evidence then: Evidence covers the complete baseline and criteria, matching units and maturity gates are enforced, history is durable and idempotent, and the organization remains unchanged observable_outcomes: - Inactive pilots and specialist reviewers cannot submit review records - Missing or duplicate metrics, mismatched units, premature adoption and unsupported success claims are rejected - Qualitative or unavailable observations cannot justify adoption recommendations - Review records label evidence reviewer-reported rather than verified - CLI lists persisted history and audits are emitted once per unique review - Configuration bytes, Git HEAD and piloting state remain unchanged - Candidate acceptance rejects missing pilot-review evidence determinism_controls: - Disposable installed Git repository and SQLite store - Controlled activation and review timestamps with no sleeps or providers anti_cheat_rationale: prevents: - Relabeling qualitative evidence as a proven improvement - An interim success recommendation automatically adopting management changes - Silent omission of unfavorable pilot criteria - Passing review storage by mutating the active organization relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Visible unknown manager launches ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-manager-wake-recovery given: An interrupted reservation in the project's real SQLite store when: The dashboard snapshot observes it before and after owner recovery then: Unknown launches are counted and identified, recovery updates the view, and observation does not change reservation records - id: SCN-dashboard-demo-browser given: The actual Console with a sample unknown manager launch when: The owner follows its attention link then: The collapsed Operations panel opens and shows the exact launch record without a restart or unlocking control observable_outcomes: - Presence is displayed separately from unknown launch outcome - Runtime termination is never claimed by the read-only projection - Attention navigation makes hidden launch details visible - Demo still has zero live API requests and no browser errors determinism_controls: - Disposable Git and SQLite fixture with simulated crash-window state - In-memory sample project and isolated loopback browser server anti_cheat_rationale: prevents: - A dashboard read silently unlocking or retrying a launch - An attention link pointing into inaccessible collapsed content - A passing source-string assertion substituting for rendered UI evidence relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Self-host acceptance requires portable wake and provider evidence ```yaml test_integrity_note: change_type: [new_tests, refactor_tests] scenarios: - id: SCN-candidate-acceptance-evidence given: Green command results but missing portable wake-policy, reservation, recovery or provider-inheritance scenario evidence when: Candidate acceptance evaluates the output then: Acceptance fails for each omitted marker observable_outcomes: - Self-host receipts require all new portability and manager safety scenarios - Provider inheritance has a unique scenario marker rather than sharing runtime-selection evidence determinism_controls: - Controlled command results at the candidate validation boundary anti_cheat_rationale: prevents: - Green exit codes standing in for missing requirement evidence - Duplicate markers masking an absent provider-inheritance scenario relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Interrupted manager wake inspection and recovery ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-manager-wake-recovery given: A persisted reservation representing a crash after a simulated provider launch when: A caller inspects or tries to recover the reservation through service and CLI then: Only an approving owner with stopped-runtime evidence and an offline manager can recover it, without invoking a provider or bypassing budget and replay guards observable_outcomes: - Inspection distinguishes blocking unknown launches from completed records without claiming runtime termination proof - Missing approval or evidence, non-owner callers, live managers and completed launches are rejected - Recovery and its evidence audit commit atomically and repeated confirmation is idempotent - The recovered message still cannot be invoked again and its daily budget charge remains - CLI inspection and recovery approval boundaries match the service determinism_controls: - Disposable installed Git repository and SQLite store - Fixed UTC clock and simulated provider invocation - Crash-window state seeded at the durable reservation boundary anti_cheat_rationale: prevents: - Age-based unlocking or silent invocation retries - Recovery that refunds budget or bypasses message replay protection - Claiming an offline heartbeat proves runtime termination relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-30 — Explicit portable manager wake policies This supersedes the earlier unconditional USD-cap requirement. The owner requires a fleet usable with Codex, Claude, Pi and local/subscription runtimes; requiring a provider feature absent from every built-in runtime prevented the requested timer behavior. Enabling count mode is a separate explicit policy choice. Existing hard-cap scenarios and their strict assertions are unchanged. ```yaml test_integrity_note: change_type: [new_tests, spec_correction] scenarios: - id: SCN-manager-check-in-count-mode given: An owner-enabled count-limited manager schedule and configured Codex, Claude or Pi identity when: A tick recovers an existing pending check-in and prepares a wake then: Real adapter plans succeed without a fabricated dollar-cap receipt, simulated invocation respects the shared UTC-day budget, and repeat ticks do not duplicate it - id: SCN-manager-wake-reservation given: One manager invocation is reserved and another schedule targets that manager when: The second schedule tries to reserve another wake then: The in-flight reservation blocks the second invocation without consuming another budget slot - id: SCN-manager-wake-policy given: Manager runtime wake configuration when: Budget mode or daily limit is absent, or count mode also promises a dollar ceiling then: Configuration validation rejects the ambiguous or unbounded policy observable_outcomes: - Disabled wakes remain disabled and timer installation is separate - Codex and Claude default profiles and explicit Pi provider/model can prepare count-limited wakes - The output explicitly reports dollarCapEnforced false in count mode - A previously unavailable preflight can retry pending delivery without creating a duplicate message - Daily limits apply across schedules and reset only across the UTC-day boundary - Concurrent manager reservations and duplicate message attempts are refused atomically - Legacy positive USD ceilings still select hard-cap mode and unsupported or mismatched receipts fail closed - Console timer review displays the shared daily limit and the selected wake policy determinism_controls: - Fixed clock, disposable Git/worktree/XDG fixtures, real adapter planning and simulated wake callbacks - No provider session, host timer, remote Git mutation or dollar expenditure anti_cheat_rationale: prevents: - Claiming invocation counts enforce dollar spending - Disabling hard-cap checks to obtain a passing subscription-runtime scenario - Counting two schedules as separate daily budgets - Stranding unreserved pending messages after an unavailable preflight - Launching overlapping manager turns or consuming quota before preflight relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Product demo and provider portability review corrections The owner explicitly clarified that the dashboard demo is the actual TORCH tool with sample data, opened separately, with no browser-tab wording in its label. This supersedes the earlier miniature four-panel preview assertions. The replacement checks strengthen the scenario through actual Console browser interactions. Provider inheritance corrects the Codex-only installation failure; explicit mixed-runtime assignments remain protected by existing tests. ```yaml test_integrity_note: change_type: [spec_correction, new_tests] scenarios: - id: SCN-dashboard-demo given: A visitor opens the landing page with no connected project when: They open the actual dashboard demo and review or confirm sample actions then: The shared Console renders and updates only tab-local sample state with zero live API calls - id: SCN-install-runtime-selection given: Generated roles inherit an installation default and explicit assignments may coexist when: The owner selects Codex alone or mixed adapters with an explicit default then: Installation respects the selected default and preserves explicit provider assignments - id: SCN-cli-install-provider-default given: A reviewed generated proposal when: The CLI previews Codex-only installation then installs a mixed fleet with Codex as default then: The dry-run is read-only and the installed identities and model defaults match the selected adapters - id: SCN-domain-runtime-inheritance given: A Codex-only Fleet identifies recurring work needing a new domain when: The manager proposes a specialist with runtime omitted or inherited then: The pending domain uses Codex and proposing does not create or start an identity observable_outcomes: - Real browser opens a separate page through the cleanly named landing link - Ready backlog items appear in Queue, matching the authoritative backlog state model - Priorities, requests, artifact feedback, approvals, and profiles update the sample project only after confirmation - Replay does not duplicate sample actions; payload drift and unreviewed actions are rejected - Reset restores sample records; mobile has no document overflow; browser emits no runtime errors - Codex inherits gpt-6-luna/high and Claude inherits sonnet - Pending architect designs accept valid Pi/custom adapter names without authorizing installation or invocation - Malformed runtime identifiers are rejected and installation retains adapter validation determinism_controls: - In-memory demo transport, fixed test clock, temporary Git fixtures, loopback browser server - Browser test intercepts and fails on every live project API request - No provider, timer, remote Git write, or persistent fleet activation anti_cheat_rationale: prevents: - Shipping a separate mock interface that diverges from the actual Console - Passing source-only markup checks while real browser controls fail - Silently forcing generated roles to Claude or losing explicit mixed assignments - Displaying ready work in an unknown-state lane relaxation: did_relax_any_assertion: true if_true_explain_spec_basis: The rejected static four-panel implementation assertions were replaced by stricter shared-Console browser and isolated-state behavior checks based on the owner's explicit correction. ``` ## 2026-09-29 — Fail-closed manager wake cost ceilings ```yaml test_integrity_note: change_type: [new_tests, runtime_budget_safety] scenarios: - id: SCN-runtime-cost-ceiling given: A scheduled identity is configured with a maximum USD amount for one wake when: TORCH plans the exact create or resume operation for its selected runtime then: The adapter must declare that launch mode and return a matching enforced-cap receipt, otherwise no launch action is produced - id: SCN-manager-check-in-cost-ceiling given: A manager check-in wake has a daily invocation budget and a per-invocation USD ceiling when: Its runtime cannot prove support for that ceiling then: The check-in remains queued, the wake is skipped, and no daily invocation reservation is consumed observable_outcomes: - Enabling a schedule wake without a positive max_usd_per_invocation is rejected - Runtime adapters declare cap-supported mode identifiers separately for create and resume - Built-in Codex, Claude, and Pi modes declare no hard spend-cap modes - A trusted fixture adapter receives the exact cap and emits a matching launch-mode receipt - A missing, unsupported, or mismatched receipt prevents the manager wake - Successful schedule evidence records the enforced mode and configured USD cap determinism_controls: - Temporary Git project, fixture adapters, fake wake executor, no provider invocation, timer installation, or real billing anti_cheat_rationale: prevents: - Treating a daily launch-count budget as a dollar budget - Treating estimated prices or post-hoc telemetry as a hard ceiling - Starting persistent/background sessions with only a print-mode budget flag - Consuming invocation quota for a wake that cannot meet its required cap relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Dedicated interactive dashboard demo page ```yaml test_integrity_note: change_type: [new_tests, static_product_demo] scenarios: - id: SCN-dashboard-demo given: A visitor opens the public TORCH landing page without a connected project when: The visitor opens the dashboard demo in a new tab and selects Overview, Work board, Agent messages, or Release gates then: The matching illustrative sample view is shown without connecting to project state or invoking an action observable_outcomes: - The landing page contains no dashboard demo workspace; its link targets a dedicated page in a new tab - The dedicated demo page is noindex and labels its records as sample data with no live project connection - All four tab controls target an existing, labelled panel - Tab state and panel visibility are updated together, with keyboard navigation declared - The demo uses a page-scoped script with no fetch or XMLHttpRequest path - Release gate examples visibly distinguish passed local evidence from open live-provider and owner-review gates determinism_controls: - Source-level public-site regression with fixed sample markup; no provider, repository API, runtime, or schedule is contacted anti_cheat_rationale: prevents: - Presenting invented dashboard records as live fleet telemetry - Coupling a standalone product demo to the landing-page scroll or making it read or mutate a visitor's project - Implying local checks equal live provider or release qualification relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Preview-confirmed Console schedule timer setup ```yaml test_integrity_note: change_type: [new_tests, schedule_launcher_control] scenarios: - id: SCN-console-schedule-launcher given: An installed Fleet has persistent system schedules and no TORCH schedule launcher installed when: The owner reviews the exact plan and confirms timer installation in the loopback Console then: Preview is read-only, stale or cross-origin confirmation is refused, only TORCH-owned unit files are installed, and the operation is audited exactly once observable_outcomes: - Every configured system schedule including behavior and exact action is included in the preview - Unit paths, content digests, project schedule digest, and timer-start effect are visible before confirmation - A changed schedule configuration after preview prevents unit creation or systemd calls - Confirmation alone performs bounded file writes and the expected systemd enable/start calls - Replay returns the same receipt without repeating systemd calls or audit events - Snapshot reports installed-file ownership/digest without claiming that systemd currently has the timer active determinism_controls: - Temporary Git project, temporary XDG data/config directories, loopback HTTP server, fake systemd executor, no provider, timer, or live user-systemd call anti_cheat_rationale: prevents: - Claiming a configured cadence is already installed - Applying a stale or cross-origin timer plan - Hiding mutating or provider-wake schedule actions from the review - Replaying a single-use owner confirmation relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Owner-confirmed Console runtime profile changes ```yaml test_integrity_note: change_type: [new_tests, dashboard_mutation] scenarios: - id: SCN-console-runtime-profile given: An installed Fleet has an identity assigned to one runtime and the owner wants to change its next-launch provider/model profile when: The owner previews and confirms the profile change in the loopback Console then: The preview is read-only and exact, stale configuration is refused, the confirmed change is audited, and running sessions are untouched observable_outcomes: - Cross-origin preview requests are rejected - The exact current and proposed runtime/model/reasoning settings are shown before confirmation - Switching adapters removes the old adapter-specific identity launch-policy override and validates the selected adapter's effective defaults - Configuration digest drift between preview and confirmation requires a fresh review - Replaying confirmation returns the same receipt without recording another profile change - The resulting owner audit event records the prior and next identity profile; no provider or runtime is started - The Console keeps profile review, confirmation, and edit as three distinct explicit controls determinism_controls: - Temporary installed Git fixture, local Console loopback server, built-in runtime adapters, no AI provider, runtime process, timer, or hosted service anti_cheat_rationale: prevents: - Bypassing the CLI's runtime capability and launch-policy validation from the dashboard - Applying a stale or cross-origin provider/model change - Implying that profile edits reconfigure an already-running session - Silently applying a profile merely because a selector changed relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Owner-confirmed fast-forward-only forge publication ```yaml test_integrity_note: change_type: [new_tests, forge_publication] scenarios: - id: SCN-forge-sync given: An attached local forge mirrors the project's canonical branch and local canonical main advances when: The owner reviews and confirms forge synchronization then: Only the exact local canonical commit is published by fast-forward, and remote-ahead or unavailable ancestry blocks without rewriting remote history observable_outcomes: - Plan is read-only and identifies local and remote commit IDs - Missing confirmation cannot update the remote ref - Confirmed synchronization publishes the expected commit and records an owner audit event - A remote tip not present locally requires an explicit fetch before ancestry can be assessed - A remote-ahead tip remains unchanged and sync fails closed after fetch - Forge loss degrades synchronization status but local integration remains operational determinism_controls: - Temporary local bare Git remotes and a side clone; no hosted forge, provider, timer, or persistent user remote anti_cheat_rationale: prevents: - Concurrent direct pushes from overwriting a newer canonical remote ref - Treating a plan-time remote observation as a force-push authorization - Coupling local integration availability to forge availability relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — FIFO canonical integration drain ```yaml test_integrity_note: change_type: [new_tests, integration_queue] scenarios: - id: SCN-integration-fifo-drain given: Multiple authorized integration requests were verified against the same canonical tip when: The landing authority drains the persistent integration queue then: Requests are considered in insertion order, each successful landing serializes, and later tips that omit the new canonical commit move to needs_convergence rather than racing or weakening checks - id: SCN-cli-integration-drain given: An installed project has an empty integration queue when: The owner invokes the CLI queue drain with and without explicit confirmation then: The unconfirmed operation is refused without changing the canonical commit, while a confirmed one-shot drain returns an empty result and still does not start a background process observable_outcomes: - Only the configured landing authority can drain or directly land a request - One authorized drain invocation is the single FIFO landing process for its ready queue - Read-only Console snapshot exposes pending queue insertion order and authorization identity - The first current candidate lands through the existing clean-target fast-forward gate - A stale later request is visibly deferred and never changes canonical main - After its owner converges the latest main and reruns exact-commit checks, a new authorized request can land determinism_controls: - Temporary Git worktrees, local SQLite state, passing fixture check, no remote, provider, background process, or timer anti_cheat_rationale: prevents: - Concurrent authorized requests from racing the canonical branch - Treating a check on an old source SHA as evidence for a converged tip - Silently merging a branch that omits a canonical commit landed ahead of it relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Owner approval decisions in the local Console ```yaml test_integrity_note: change_type: [new_tests, dashboard_mutation] scenarios: - id: SCN-console-owner-approval given: Pending structured approvals are assigned either to the project owner or to a manager AI when: The owner previews and confirms a decision in the local Console then: Only owner-addressed requests can be decided, the exact current revision is rechecked, the requester is notified once, and stale, cross-origin, or replayed actions do not apply observable_outcomes: - Owner decision preview is mutation-free and presents requester, evidence, revision, note, and effect - Confirmation delegates to the existing audited approval transaction - A non-owner approver remains the sole decision-maker for its request - Concurrent completion invalidates the preview and repeated confirmation is idempotent determinism_controls: - Temporary Git repository, local SQLite state, loopback HTTP server, no provider, timer, or runtime wake anti_cheat_rationale: prevents: - Owner UI from silently overriding a manager or peer-AI approval target - Stale review from deciding a changed request - A retry from creating duplicate approval decisions or requester notifications relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Project integration gates in specialist prompts ```yaml test_integrity_note: change_type: [spec_clarification, new_tests] scenarios: - id: SCN-project-gates-in-domain-prompt given: A project has repository-wide checks but no evidence-backed domain-specific check mapping when: TORCH generates an implementation specialist prompt then: The prompt shows exact project integration check IDs and argv separately without claiming specialist ownership observable_outcomes: - Every specialist receives repository-wide integration gates configured for the project - Domain-specific required_checks remain unchanged unless separately reviewed and evidenced determinism_controls: - Temporary Git fixture with a package script and no AI provider or runtime command execution anti_cheat_rationale: prevents: - Hiding the gates all domains must pass before integration - Inventing test ownership from names or keyword similarity relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Manager check-in cadence floor ```yaml test_integrity_note: change_type: [new_tests, spec_correction] scenarios: - id: SCN-manager-check-in-cadence-floor given: A project configuration has an owner-authorized manager check-in interval when: The configured cadence is 59 seconds or exactly 60 seconds then: The 59-second cadence is rejected at the project-config boundary and the 60-second cadence remains valid observable_outcomes: - Invalid high-frequency polling produces a path-specific configuration error before timer reconciliation or runtime wake - One-minute manager polling remains configurable and ordinary schedules are unchanged determinism_controls: - In-memory project-config fixture; no timer, provider, runtime, or wall-clock access anti_cheat_rationale: prevents: - Installing accidentally sub-minute manager polling that can flood durable check-ins - Rejecting the 60-second minimum already enforced by the generated-schedule helper relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Candidate untracked-input visibility ```yaml test_integrity_note: change_type: [new_tests, spec_clarification] scenarios: - id: SCN-candidate-untracked-visibility given: A clean committed Git candidate source has one ignored local file and one non-ignored untracked source file when: The owner reviews and stages the candidate then: The plan lists the untracked source path, the staged artifact excludes it, and ignored local data remains neither listed nor copied observable_outcomes: - Candidate source identity remains bound to the exact Git commit - The review plan exposes every non-ignored untracked path omitted from the candidate - Ignored local files and untracked source files do not enter the staged artifact determinism_controls: - Temporary Git candidate repositories with a committed ignore file and fixed local files; no network, provider, or current checkout mutation anti_cheat_rationale: prevents: - Mistaking the exact committed candidate for a copy of the full working tree - Silently hiding excluded, non-ignored source changes from the candidate review - Leaking ignored local data into the installed artifact relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Specification responsibility attribution ```yaml test_integrity_note: change_type: [spec_correction, new_tests] scenarios: - id: SCN-spec-evidence-grounding given: A repository has an implementation domain and its external specification has a similarly named prose-only responsibility with no repository path reference when: TORCH creates the deterministic baseline and Session Architect brief then: The requirement remains an unrepresented review signal and is not appended to the implementation domain based on keyword overlap observable_outcomes: - Existing repository ownership stays grounded in actual analyzed paths - Pathless specification responsibilities remain visible for semantic architect and owner review - Specification-only projects may propose provisional groups but must retain missing ownership status determinism_controls: - Temporary Git fixture, fixed external Markdown specification, local filesystem path checks, no AI provider or project mutation anti_cheat_rationale: prevents: - Converting overlapping terminology into unsupported implementation ownership - Hiding specification responsibilities that need human or architect review relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Serialized landing and resume instruction freshness ```yaml test_integrity_note: change_type: [spec_correction, new_tests] scenarios: - id: SCN-integration-landing-serialization given: Two independent control-plane connections target the same project landing queue when: One holds the project SQLite write transaction and the other attempts to land an authorized request then: The competing lander fails with a retryable busy result without moving the canonical branch, and can land after the lock is released - id: SCN-current-instructions-on-resume given: A resumed identity has stale prompt copies in its worktree while canonical project prompts have changed when: TORCH plans and executes the resume and creates the Fleet brief then: The digest-addressed latest canonical bundle includes the current organization role/report context, is delivered, and the brief exposes the same digest observable_outcomes: - Competing landing cannot perform a stale preflight and mutate the canonical ref during another project writer's transaction - Claude and Pi receive current prompt files; Codex receives the current instruction envelope in its resume turn - Prompt digest changes when authoritative instructions change and stale worktree files are ignored - A changed owner-approved organization graph updates generated role context before resume without changing implementation ownership determinism_controls: - Temporary Git repositories, independent SQLite handles, fake runtime executors, and changed local prompt fixtures; no provider or network access anti_cheat_rationale: prevents: - Treating sequential readiness checks as sufficient concurrency control - Reusing old runtime conversation instructions after policy changes - Treating a stale worktree prompt as authoritative relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Organization-aware lifecycle ordering ```yaml test_integrity_note: change_type: [spec_correction, new_tests] scenarios: - id: SCN-hierarchy-aware-start-stop given: A project has an owner-facing manager, a middle manager, and a specialist reporting through that manager when: TORCH plans startup and wind-down and executes them with fake runtimes then: Managers start before direct reports, stop after them, and final status is routed to each direct reporting manager - id: SCN-hierarchy-startup-cycle given: An acyclic role graph binds multiple roles to identities whose collapsed reporting graph contains a cycle when: TORCH plans startup or wind-down then: Both plans expose an identity-cycle blocker and no runtime executor is called observable_outcomes: - The returned startup and shutdown order follows the active organization graph rather than roster order or a hard-coded manager exception - Each planned identity lists its direct manager identities - Wind-down status messages go to direct managers, allowing reports to reach managers level by level - Identity cycles block launch and shutdown before runtime mutation - Legacy session_manager.start_last configuration is accepted but does not override graph ordering determinism_controls: - Temporary Git repositories/worktrees, one three-level organization fixture, a role graph whose identity projection cycles, and fake runtime executors - No real provider, system timer, or live Fleet process anti_cheat_rationale: prevents: - Passing lifecycle checks using flat roster order while ignoring middle management - Routing every specialist wind-down report only to the Session Manager - Launching a partially ordered Fleet when persistent identities collapse an acyclic role graph into a cycle relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Organization-aware manager check-in queue ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-manager-check-in given: A manager has direct reports with waiting status and unacknowledged blocker messages when: TORCH plans and queues a manager check-in then: Findings are scoped to the active reporting graph, structured approval waits name the requester and approver, unstructured status is not treated as approval, one durable self-directed request is queued, and a pending request is deduplicated - id: SCN-manager-check-in-refresh given: A durable manager check-in is pending and new direct-report approval requests arrive after its timestamped snapshot when: The bound manager reads the wake and refreshes current check-in state then: A read-only identity-bound MCP tool returns the latest reports and named approval waits; specialists cannot use it to inspect manager reports - id: SCN-manager-check-in-specialist given: A specialist identity has no direct reports when: TORCH builds its check-in plan then: The plan has no direct reports and creates no spurious attention - id: SCN-manager-schedule-coverage given: An active organization graph has multiple manager identities with direct reports when: TORCH validates the installed schedule configuration then: Every manager identity must have its own owner-authorized system check-in cadence or configuration is rejected - id: SCN-manager-check-in-schedule given: An owner-approved system schedule names a manager check-in coordination action and its manager is offline when: The system dispatcher reaches the configured interval then: TORCH queues the direct-report request, records run evidence, preserves offline identity state, and makes no provider or shell command call - id: SCN-manager-check-in-budgeted-wake given: An owner-reviewed manager schedule explicitly enables runtime wake with a daily invocation cap when: A check-in is queued for an offline manager and the cap is later exhausted then: An injected runtime waker is called at most within the atomic cap; a missing waker blocks dispatch, active managers are not awakened, and durable check-ins remain queued - id: SCN-default-manager-checkin-config given: A deterministic project fleet proposal is generated when: The owner reviews its validated schedules then: It includes a 15-minute Session Manager check-in schedule but does not install or start a system timer - id: SCN-manager-schedule-growth given: A proposed organization graph adds or removes direct reports under managers when: TORCH plans schedule coverage for the hierarchy then: Missing managers receive a default owner-authorized cadence, existing cadence is preserved, and obsolete schedules are surfaced without removal or activation observable_outcomes: - Read-only planning reports direct-report status, tasks, blockers, and unacknowledged messages - Pending direct-report requests are classified by named manager, peer-AI, or owner approver - A queued check-in labels its snapshot as potentially stale and instructs the manager to refresh current durable state before acting - The read-only manager refresh is scoped to the bound identity and active direct-report graph; it grants no approval authority - Only the named approver can decide; decisions are revision-checked, audited, and durably returned - Owner decisions require explicit CLI confirmation and cannot be claimed through a Fleet MCP identity - Queuing a request does not launch or steer an AI runtime - A schedule tick is authority-gated and duplicate pending requests do not create duplicate inbox entries - Runtime wake is disabled by default, runtime/provider calls are represented only by an injected test waker, and one durable atomic daily invocation reservation is shared across manager schedules - Deterministic project proposals include a default check-in schedule while timer installation remains a separate owner action - Hierarchy planning derives coverage for every manager identity while preserving configured cadence and requiring separate activation determinism_controls: - Temporary local Git fixtures, fixed project graph, local SQLite state, fake command and wake executors, and no provider runtime or timer installation anti_cheat_rationale: prevents: - Scanning agents outside the manager's direct-report scope - Treating free-text waiting summaries as authorization or approval state - Allowing a manager to approve a request assigned to another identity - Duplicating unacknowledged check-in messages on repeated checks - Claiming a provider session was awakened by durable inbox delivery relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Read-only manager and approval flow watch ```yaml test_integrity_note: change_type: [new_tests, dashboard_observability] scenarios: - id: SCN-console-manager-check-ins given: An installed organization has a waiting direct report with a structured approval assigned to the owner when: The owner observes the local Console snapshot and opens Flow watch then: The snapshot shows the manager, direct-report state, named approver, approval evidence, and cadence while explicitly not claiming timer installation or performing a decision observable_outcomes: - Read-only SQLite observation returns scoped manager reports and pending approvals without altering Git or project state - Owner approvals appear in the attention queue and flow watch; summaries are escaped and private model reasoning is not exposed - Timer state is reported as unverified, not inferred from a configured schedule - Snapshot endpoint remains GET-only and Flow watch has no approval mutation controls determinism_controls: - Temporary repository and SQLite fixture, fixed clock, local HTTP server, no provider, systemd query, or runtime launch anti_cheat_rationale: prevents: - Treating a configured schedule as proof its timer is active - Inferring approval from vague presence text - Letting dashboard observation mutate approval or manager state relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Versioned organization graph foundation ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-organization-graph given: A versioned organization graph with an owner, owner-facing role, coordinator, and specialist when: TORCH validates the graph, a specialist promotion, invalid ownership, authority leakage, or invalid reporting links then: Valid structures are retained and duplicate implementation owners, owner-only authority leakage, cycles, and unknown role references are rejected observable_outcomes: - Organization graph validator returns the unchanged valid graph or a typed validation error with field evidence - The installed project configuration schema accepts the versioned organization graph - A specialist identity may hold both specialist and coordination roles without moving implementation ownership determinism_controls: - In-memory fixed graph fixtures; no clock, random IDs, model calls, or network access anti_cheat_rationale: prevents: - Accepting multiple implementation owners for one surface - Granting release or organization approval authority to a coordinator - Treating reporting cycles or unknown role links as valid - Forcing promotion to transfer implementation ownership relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Adapter-specific launch-policy profiles ```yaml test_integrity_note: change_type: [new_tests] scenarios: - id: SCN-runtime-launch-policy given: Installed identities with runtime-default and identity launch policies for Codex, Claude, and a custom adapter when: TORCH resolves launch plans or the owner changes project-local policy then: Supported values inherit/override and map to adapter flags, unsupported or unsafe/conflicting values block before execution, legacy Codex defaults migrate without changing their invocation, and edits require --yes without starting sessions observable_outcomes: - Codex sandbox/approval flags and Claude permission-mode flags match validated policy values - Pi and undeclared custom adapters reject policy overrides; fixed Pi safety flags are not weakened - Profile inspection exposes effective launch policy and profile mutations only alter future launch plans determinism_controls: - Temporary local Git repository and deterministic adapter plans; no provider process, network, clock, or live runtime anti_cheat_rationale: prevents: - Silently dropping or substituting unsupported policy values - Combining Codex approve-for-me with an explicit sandbox - Exposing Claude bypassPermissions as an ordinary profile setting - Letting policy edits start sessions or change running identities relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Project-scoped saved backlog views ```yaml test_integrity_note: change_type: [new_tests, interface_redesign] scenarios: - id: SCN-console-saved-views given: An authoritative backlog snapshot and a browser-local project preference store when: An owner filters tasks, saves or updates a named view, reloads it, or deletes it then: The board shows matching active tasks while task records and server state remain unchanged - id: SCN-console-saved-views-storage given: Malformed browser preferences or unavailable/quota-limited browser storage when: The Console loads or saves a view then: Invalid views are ignored, the authoritative unfiltered backlog remains usable, and save failures explain that no task data changed observable_outcomes: - Saved filters are scoped by stable project identity and contain only bounded names and filter values - Owner, state, priority, domain, and text filters combine against current backlog fields - Static serving exposes only the fixed work-view asset; the snapshot API remains GET-only determinism_controls: - Fixed in-memory task objects, injected local-storage doubles, and temporary local repository; no provider, server-side write, or task mutation anti_cheat_rationale: prevents: - Creating another backlog or copying task state into browser preferences - Applying one project's filters to another project - Hiding storage failures while implying a view was persisted - Letting malformed preferences affect the authoritative work board relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Evidence-scoped shared path proposals ```yaml test_integrity_note: change_type: [spec_clarification] scenarios: - id: SCN-domain-collision given: Two domains import a shared source contract while repository-wide package and configuration files are also present when: The deterministic domain baseline is generated then: Each importing domain lists the actual shared contract, dependency evidence creates coordination, and unrelated repository-wide candidates are not blanket-assigned as shared writable paths observable_outcomes: - Shared ownership in the baseline is derived from component dependency edges and exact target paths - Remaining shared candidates stay visible in architecture review evidence for Session Architect and owner review determinism_controls: - Fixed source imports and local Git fixture; no provider call or project mutation anti_cheat_rationale: prevents: - Treating all configuration and untracked repository files as writable by every specialist - Hiding real cross-domain contract ownership behind an empty shared-path list relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Adaptive owner cockpit observation and scoped feedback ```yaml test_integrity_note: change_type: [new_tests, interface_redesign] scenarios: - id: SCN-console-readonly given: An installed Fleet with durable backlog metadata and local runtime configuration when: The owner opens the local Console and its observation endpoint then: The responsive dashboard projects task dependencies, identity profiles, conversations, provenance, gates, and attention state without mutating the repository; its snapshot endpoint remains GET-only observable_outcomes: - Snapshot contains the authoritative backlog fields needed for a kanban projection and runtime/model/reasoning profile fields - Missing screenshot/artifact provenance is identified as unavailable rather than represented as an empty verified gallery - Console assets render a pulse, work board, attention queue, and accessible responsive navigation - POST requests to the observation endpoint are refused determinism_controls: - Fixed local repository and state fixtures; no provider call, hosted service, or write action through the observation endpoint anti_cheat_rationale: prevents: - Rendering a dashboard board from a second, divergent task source - Hiding missing artifact provenance behind a fabricated gallery - Treating read-only dashboard rendering as owner authorization - Exposing private model reasoning in the communication feed relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Adaptive organization proposals and per-identity runtime profiles ```yaml test_integrity_note: change_type: [new_tests, spec_clarification] scenarios: - id: SCN-hierarchy-proposal given: A versioned active organization and repeated coordination evidence when: The Session Manager submits or deduplicates a hierarchy proposal, or an owner reviews it then: Sustained evidence and alternatives are required, only the configured owner may decide, implementation ownership remains unchanged, and activation requires a separate fresh plan and owner confirmation - id: SCN-hierarchy-reconsideration-after-new-evidence given: A hierarchy proposal that was rejected by the owner when: The Session Manager submits the same proposed graph with a later evidence window and new references then: The new evidence creates a fresh owner-review proposal while exact retries of that evidence remain idempotent - id: SCN-hierarchy-pressure-assessment given: A project with a configured observation window and durable coordination records when: The Session Manager assesses recurring organization pressure then: The tool reports only dated in-window evidence, requires recurrence or multiple signals, refuses specialist authority, and never creates or activates a proposal - id: SCN-hierarchy-proposal-mcp given: An MCP server bound to the Session Manager identity when: It proposes, lists, reads, or plans an organization change then: The manager can prepare owner-review material but no owner-decision tool is exposed - id: SCN-hierarchy-cli given: A durable hierarchy proposal created by the Session Manager when: A caller attempts owner review through the CLI then: A coordination identity is refused, the configured project owner may approve a bounded pilot, and the pilot plan remains non-mutating - id: SCN-hierarchy-activation given: A fresh, owner-approved hierarchy pilot that promotes an existing identity and leaves the project clean when: The owner previews and separately confirms pilot activation then: The committed graph and required manager schedules change together while identities, implementation ownership, active tasks, systemd units, and runtime sessions remain untouched - id: SCN-hierarchy-activation-rollback given: A fresh owner-approved hierarchy pilot and a local Git hook that rejects its activation commit when: The owner confirms pilot activation but Git refuses the scoped commit then: Canonical config, install manifest, pilot record, and index return to their exact prior state and the proposal remains approved for retry - id: SCN-console-hierarchy-activation given: An owner-approved hierarchy pilot is shown in the local Console when: The owner previews activation, repository state changes, then reviews and confirms a fresh plan then: Cross-origin and stale requests are refused, a fresh one-use confirmation creates exactly one scoped activation commit, and no session or timer is started - id: SCN-runtime-profiles given: Multiple identities assigned distinct registered runtime adapters and model/reasoning profiles when: TORCH plans startup, diagnoses identities, and the owner edits installed project-level profile defaults then: Each effective profile is routed to its selected adapter, supported config changes affect only a future launch plan, unsupported capabilities block startup with explicit findings, and TORCH does not silently substitute a provider - id: SCN-runtime-profile-cli given: An installed project with configured runtime defaults and persistent identities when: The owner inspects profiles, changes an identity/default, resets identity overrides, or omits explicit confirmation then: Writes require --yes, validate the resulting config, preserve identity overrides above runtime defaults, and never start or change a running session - id: SCN-pi-adapter given: A fleet identity assigned the built-in Pi adapter with a user-selected provider/model profile when: TORCH plans a fresh or resumed session then: It uses Pi's resumable-turn CLI, scoped prompt and transcript directory, explicit model/thinking selection, and a required model without starting Pi during planning - id: SCN-pi-mcp-bridge given: A TORCH-bound Pi extension and a local project with an approved roster identity when: Pi invokes a registered TORCH tool through the bundled MCP bridge then: The extension exposes the complete MCP tool set, binds calls to the configured identity, rejects identity spoofing, and shuts down the per-call MCP process without invoking an AI provider observable_outcomes: - Hierarchy evidence, decisions, and candidate graph revision persist in the local control-plane database without editing active config or roster - A hierarchy pilot plan records graph delta, resulting manager schedules, timer reconciliation requirement, affected active backlog, worktrees, preservation promises, and blockers - Explicit pilot activation updates canonical organization and schedule config, install-manifest hashes, and a durable pilot record in one scoped Git commit; no identity, worktree, timer, or provider is started - The Console activation preview exposes the exact fresh pilot plan, owner identity, active work, manager cadence delta, blockers, and systemd reconciliation requirement; stale preview cannot activate - Replaying a consumed Console activation token returns the same result without creating a second commit - When an exact-config timer exists, activation leaves its units unchanged and reports the required separate reconciliation; successful reconciliation applies the new manager cadence, while a failed activation commit leaves the proposal and timer untouched - Runtime startup plans report the selected adapter and per-identity profile - Identity/agent queries and dashboard snapshots expose the effective runtime defaults plus any per-identity overrides - Editing installed runtime defaults updates future launch plans and dashboard snapshots without starting or stopping a session - Pi launch plans retain the same Pi session identifier and isolate transcript data under local TORCH project state - Pi extension tools match the MCP server manifest and cannot claim another roster identity determinism_controls: - Fixed project fixtures, explicit timestamps and identities, registered test adapters, no provider calls, and temporary local Git repositories anti_cheat_rationale: prevents: - Promoting a role from a single uncorroborated observation - Treating a manager proposal as owner approval or as live organization state - Transferring implementation ownership through coordination hierarchy changes - Claiming a runtime supports model or reasoning controls it does not implement - Silently replacing an unavailable or unsupported runtime profile - Loading arbitrary project Pi extensions into TORCH Pi sessions - Allowing a Pi model to escape its identity-bound TORCH MCP context relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Provenance-backed visual evidence and routed owner feedback ```yaml test_integrity_note: change_type: [new_tests, interface_redesign] scenarios: - id: SCN-artifact-review given: An installed Fleet, one assigned task, a publishing identity, a full Git commit, and a bounded image in that identity worktree when: The identity publishes the image, then the owner previews and confirms feedback through the CLI or the local Console then: TORCH preserves task, identity, runtime-session, commit, and digest provenance; routes the comment as a durable message to the task owner; and serves only digest-verified bytes - id: SCN-artifact-boundaries given: Artifact publication or feedback input with an unknown task, abbreviated commit, symlink, path traversal, wrong actor, or tampered content when: TORCH validates or serves the item then: The operation fails with a typed error and does not claim the image is verified observable_outcomes: - Images are copied into private project-local external state, never checked into the project repository by the artifact service - Feedback preview is mutation-free; only the configured owner can create the durable message, linked to artifact, task, and exact commit - The observation endpoint remains GET-only; Console feedback requires same-origin loopback JSON and a single-use five-minute preview token bound to the exact message effect - Stale, expired, cross-origin, and replayed confirmations are refused without adding a message - The Console displays comments without exposing private model reasoning or changing backlog state - Content tampering is rejected by the serving route and marked unavailable in the snapshot determinism_controls: - Temporary local Git repository, one-pixel fixed PNG, deterministic runtime identity, local SQLite, and loopback fixture HTTP; no provider or hosted network calls anti_cheat_rationale: prevents: - Attaching an image to a task not owned by its publishing identity - Accepting an abbreviated or missing commit as exact provenance - Traversing symlinks or copying external files into the gallery - Treating a feedback preview as an owner decision - Letting a cross-origin caller forge owner feedback or replay a prior confirmation - Serving tampered image bytes as trusted visual evidence - Adding a second comment ledger beside durable inter-session messages relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — User-trusted local runtime adapters ```yaml test_integrity_note: change_type: [new_tests, security_boundary] scenarios: - id: SCN-runtime-plugin-trust given: A local CommonJS adapter module that is not in TORCH's user-local trust store when: The owner previews trust, edits the module after preview, approves the stale digest, lists adapters, loads the reviewed plugin, and later revokes trust then: Preview/list never execute the module; approval requires the exact reviewed SHA-256; changed code fails closed; the adapter runs only after trust; revocation does not claim to stop running sessions - id: SCN-runtime-plugin-lifecycle given: An installed Fleet whose project configuration initially uses only a built-in adapter and a separately user-trusted local plugin when: The owner assigns that plugin to one identity and TORCH plans the mixed Fleet then: Project-local profile configuration may select the already-trusted adapter, the launch plan uses its declared model/reasoning/capabilities, and the plan starts no runtime observable_outcomes: - Trust records are user-local, outside project-controlled configuration, and pin the canonical entrypoint SHA-256 - Trust and revocation require --yes plus the exact hash shown by the review plan - Project configuration cannot register a module path or authorize plugin code - Runtime plugin load failures are surfaced in the registry/doctor; no provider substitution occurs - Profile selection may add a locally trusted adapter's declared configuration to the project without starting or stopping sessions determinism_controls: - Synthetic local adapter with a load sentinel, temporary XDG config/data roots, and temporary Git repository; no network or AI provider calls anti_cheat_rationale: prevents: - Executing a plugin during trust preview or runtime catalog listing - Reusing owner approval after the entrypoint changes - Letting project-edited JSON invent a trusted adapter or executable path - Treating an adapter launch plan as evidence that a provider was started relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Backlog-derived feature and milestone progress ```yaml test_integrity_note: change_type: [new_tests, dashboard] scenarios: - id: SCN-backlog-classification given: A backlog task with an explicit revision and a Session Manager identity when: The manager classifies or clears its feature and milestone labels through the service, CLI, or MCP tool then: TORCH revision-checks and audits only the labels; task ownership, state, evidence, dependencies, and queue order remain unchanged - id: SCN-console-initiative-rollups given: Backlog tasks with explicit feature and milestone labels, including completed, cancelled, blocked, active, and unlinked tasks when: The Console derives progress summaries then: It groups only explicitly labeled tasks, excludes cancelled tasks from the completion denominator, reports risk and task-state counts, and does not alter source records observable_outcomes: - Feature and milestone labels remain optional fields on the authoritative backlog task, not a parallel initiative ledger - Classification is manager-only, reasoned, revision-checked, and retained in task-local history plus the audit stream - Unlabeled tasks remain ungrouped; names and completion are never inferred from paths, domains, or prose - Progress percentages describe task states only and cannot imply passing tests, integration, release, deployment, or live verification determinism_controls: - Fixed task fixtures and browser helper execution; no provider calls, network calls, or live project mutation anti_cheat_rationale: prevents: - Treating dashboard percentages as release or quality qualification - Introducing a competing feature/milestone queue - Letting specialists or stale revisions change project classification - Silently fabricating labels for unclassified work relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Preview-confirmed owner backlog reprioritization ```yaml test_integrity_note: change_type: [new_tests, security_boundary, dashboard] scenarios: - id: SCN-owner-backlog-priority given: A backlog task with a current revision and a local project owner when: The owner previews and confirms a reasoned priority change, or a specialist attempts the same operation then: Only owner authority can apply a revision-checked change; task state, owner, dependencies, and evidence stay unchanged; history and audit record the change - id: SCN-console-priority-confirmation given: An installed Fleet task and the loopback Console when: The owner previews a priority change, the task changes concurrently, a request comes cross-origin, or a token is replayed then: Only a fresh same-origin preview confirmation applies the exact reviewed effect; stale, cross-origin, expired, and replayed requests fail without an additional mutation observable_outcomes: - Preview is mutation-free and identifies task, revision, previous/new priority, reason, and bounded effect - Confirmation consumes a five-minute single-use token and recomputes the revision-bound plan before writing - Owner priority changes have durable task history and a control-plane audit event - Snapshot remains GET-only and the Console gains no task-state, assignment, evidence, integration, release, or lifecycle write route determinism_controls: - Temporary installed Git fixture, local SQLite state, and loopback HTTP requests; no provider or hosted network calls anti_cheat_rationale: prevents: - Applying a priority selected after preview without renewed confirmation - Reusing a stale revision or confirmation token - Crossing origin boundaries to invoke owner actions - Treating reprioritization as authority to reassign work or claim task completion relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Dark TORCH product surface and v1 mark ```yaml test_integrity_note: change_type: [interface_redesign, asset_reuse] scenarios: - id: SCN-torch-brand-surface given: The public TORCH site and loopback Fleet Console when: Both surfaces load their shared design tokens and brand assets then: Dark color-scheme is the default, accessible text/status contrast remains intentional, and the actual v1 torch mark is used as the wordmark icon and browser favicon observable_outcomes: - The source v1 SVG is confirmed from the legacy/nostr-torch branch and served through a fixed local asset route - Both public and Console HTML reference the same torch mark and declare a dark browser theme color - Responsive layout, focus indicators, and reduced-motion behavior remain in the shared stylesheet determinism_controls: - Static markup/style assertions and loopback fixed-asset route test; no browser extension or network resource required anti_cheat_rationale: prevents: - Replacing the historical logo with a lookalike glyph - Applying dark mode only to the Console while leaving the public product page inconsistent - Referencing an external or unpinned logo asset relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Preview-confirmed owner task proposals ```yaml test_integrity_note: change_type: [new_tests, authority_boundary, dashboard] scenarios: - id: SCN-owner-backlog-create given: An installed Fleet with a configured owner and Session Manager when: The owner plans and creates a new task proposal, or a specialist attempts either operation then: Only owner authority can propose the task; it is audited, proposed, unassigned, and leaves dispatch authority with the Session Manager - id: SCN-console-task-create-confirmation given: An installed Fleet and the local loopback Console when: A task proposal is previewed, altered, confirmed, replayed, or submitted cross-origin then: Only a fresh same-origin confirmation creates the exact reviewed proposal; changed inputs and cross-origin calls do not mutate the backlog, and an exact retry returns the same task without creating another observable_outcomes: - Preview records exact normalized task fields, observed commit, routing suggestions, dependencies, and the proposed/unassigned effect without writing a task - Confirmation uses a five-minute token bound to the reviewed plan; each token creates at most one task - Domain selection records affected domains only; it does not bind implementation ownership or dispatch work - Owner action is durably audited and does not alter runtime/session state - Existing Session Manager task creation and assignment authority remain unchanged determinism_controls: - Temporary installed Git fixture, local SQLite state, and same-origin loopback HTTP requests; no provider turn or live project write anti_cheat_rationale: prevents: - Treating routing suggestions as specialist assignment - Creating work on stale or changed preview content - Replaying a browser retry into duplicate task records - Escalating the owner interface into task-state or runtime lifecycle authority relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Owner review of Fleet and hierarchy proposals ```yaml test_integrity_note: change_type: [owner_authority, dashboard, state_transition] scenarios: - id: SCN-console-organization-review given: An installed TORCH Fleet with proposed Fleet and hierarchy changes when: The owner previews, tampers with, confirms, or replays a proposal decision then: Only a fresh same-origin preview can record the reviewed owner decision, and no decision directly activates organization state or starts an agent observable_outcomes: - Preview is mutation-free and displays the current proposal, scope, evidence, effect, owner identity, and repository head - Hierarchy preview shows manager check-in schedule additions/obsolete candidates and reports timer installation as unverified; any config-bound timer reconciliation remains a separate step - Schedule-launcher reconciliation refreshes the digest-bearing service for newly added manager schedules, refuses changed or missing owned units, updates the manifest only after validation, and restores exact prior unit and manifest state if systemd reload fails - Confirmation rechecks the proposal state, active graph, current head, and exact plan hash; stale and cross-origin requests are refused - Fleet approval only authorizes a later activation review; hierarchy approve-pilot does not itself activate, and a separate activation rejects stale, dirty, unapproved, or non-owner plans - A successful owner decision is audited by the existing proposal services and exact retries do not create duplicate effects - Organization review controls use the existing proposal ledgers; they do not write the active graph, provision worktrees, or launch providers determinism_controls: - Temporary installed Git fixture, local SQLite state, and loopback HTTP requests; no provider or hosted network calls anti_cheat_rationale: prevents: - Treating a staged approval as activation, runtime launch, or hierarchy adoption - Applying a decision after the proposal, active graph, or current repository head changed - Replaying or forging a consequential owner action from another origin - Creating a second dashboard-only organization proposal ledger relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Installed Pi extension startup without a model turn ```yaml test_integrity_note: change_type: [new_tests, runtime_adapter, provider_boundary] scenarios: - id: SCN-pi-installed-extension-startup given: An installed Pi CLI and TORCH's bundled identity-bound extension when: Pi starts in offline, no-session RPC mode with no prompt and requests only its state then: The extension loads, its TORCH-specific flags are accepted, RPC responds, and no extension error or provider turn occurs observable_outcomes: - Pi's extension API resolves its declared TypeBox runtime dependency from TORCH's installed package - Local adapter qualification checks the actual installed Pi loader rather than only a mocked registration API - Missing Pi is reported as a skipped host-specific smoke test; a present but incompatible Pi fails the scenario determinism_controls: - PI_OFFLINE=1, PI_TELEMETRY=0, isolated temporary Pi config/session paths, --no-session, and no prompt anti_cheat_rationale: prevents: - Treating mocked extension registration as proof that Pi can load the distributed extension - Calling a model or depending on provider credentials to qualify local extension loading - Allowing project extension discovery or project trust during the smoke test relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Preview-confirmed owner agent requests ```yaml test_integrity_note: change_type: [owner_authority, durable_messaging, dashboard] scenarios: - id: SCN-console-owner-agent-request given: An installed Fleet, an approved roster identity, and an optional active backlog task when: The owner previews, changes, confirms, replays, or submits a request cross-origin then: Only a fresh exact preview can write one audited durable message to the selected inbox; backlog, ownership, identity state, and runtime lifecycle remain unchanged observable_outcomes: - Preview identifies exact recipient, title, message body, optional task reference, active graph, repository head, and no-start/no-reassignment effect - Confirmation recomputes that plan; altered input, changed repository, unknown task, cross-origin, expired, and replayed requests fail closed - Owner identity is checked against the active organization graph and the durable owner message is visible through existing conversation reads - Idempotent retry returns the original message without adding a second inbox item or audit action determinism_controls: - Temporary installed Git fixture, local SQLite state, and same-origin loopback HTTP requests; no provider or runtime launch anti_cheat_rationale: prevents: - Turning an owner request into a new task queue or silent assignment - Starting or waking an agent as a side effect of sending a message - Reusing a preview after its request text or repository evidence changed - Allowing non-owner identities or cross-origin pages to create owner requests relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — COMBATRIG backlog migration assessment ```yaml test_integrity_note: change_type: [new_tests, importer_compatibility] scenarios: - id: SCN-combatrig-backlog-assessment given: A legacy fleet repository has roster-backed areas, a manager-area queue, an unknown historical area, free-form assignee names, and legacy terminal statuses when: Torch builds a read-only compatibility proposal then: It reports counts and unmapped references, does not infer identity ownership, does not create backlog tasks, and distinguishes legacy done from verified Torch completion observable_outcomes: - Backlog inventory reports counts by source area and status plus unmapped source areas - The ai-sessions alias is visible as Session Manager queue history requiring review, not specialist implementation ownership - Free-form assignedTo values are not treated as runtime identity IDs - Legacy done is not marked as completed without target commit, evidence, and landed integration provenance - Repository Git status is unchanged by compatibility analysis determinism_controls: - Temporary Git fixture with four fixed backlog items; no actual COMBATRIG writes, task creation, provider, or runtime anti_cheat_rationale: prevents: - Silently discarding queue items from retired or unmapped areas - Converting display names to executable runtime identities - Bypassing Torch's verified-completion evidence gate - Claiming migration when only a status count was inventoried relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Candidate failure diagnostics ```yaml test_integrity_note: change_type: [new_tests, candidate_acceptance] scenarios: - id: SCN-candidate-failure-diagnostics given: Candidate acceptance checks return both stdout and stderr and one check fails when: TORCH reports the candidate acceptance result then: The failed check includes bounded output excerpts while successful checks do not duplicate their logs observable_outcomes: - Test failures and subprocess errors include actionable captured output in candidate build diagnostics - Excerpts are bounded to 12,000 characters per stream and retain the final output where the likely failure cause appears - Successful validation receipts preserve check status and output byte counts without embedding full logs determinism_controls: - Injected child-process results; no filesystem, provider, runtime, or network use anti_cheat_rationale: prevents: - Reporting a failed candidate without the reason needed to fix it - Dumping unbounded process output into CLI errors and validation receipts - Duplicating successful test logs into persistent metadata relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-28 — Candidate acceptance evidence completeness ```yaml test_integrity_note: change_type: [new_tests, reliability_fix] scenarios: - id: SCN-candidate-acceptance-evidence given: The self-host candidate manifest lists required acceptance scenarios when: TORCH maps test output markers into the candidate validation receipt then: Every required scenario has one or more explicit markers, and missing evidence prevents candidate acceptance observable_outcomes: - The evidence mapping keys exactly match the required acceptance scenario list - Hierarchy activation, manager check-in schedules, and approval routing must be present in test output before their scenarios are accepted - An unmapped or marker-free required scenario can never pass through an empty evidence condition determinism_controls: - Synthetic check output with all mapped markers, followed by a run missing one hierarchy activation marker - No repository mutation, runtime, timer, or provider access anti_cheat_rationale: prevents: - Treating test and lint exit codes as proof that every declared product scenario was exercised - Quietly accepting newly added required scenarios without corresponding test evidence relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Candidate acceptance state isolation ```yaml test_integrity_note: change_type: [reliability_fix, new_tests, spec_completion] scenarios: - id: SCN-candidate-acceptance-isolation given: Candidate validation is launched while the installer has a configured XDG data home when: TORCH runs candidate test, lint, and syntax gates then: Every child uses a disposable temporary HOME, TMPDIR, and XDG roots distinct from the candidate version store, and those roots are removed after validation observable_outcomes: - The inherited installation XDG data root is not passed to acceptance children - All three gates share only the isolated temporary user-state roots - Acceptance cleanup removes the temporary roots after success or failure - Candidate activation and the active version pointer remain untouched determinism_controls: - Injected child-process runner captures exact cwd and environment without running a provider or timer - Candidate version storage and acceptance HOME use distinct temporary roots anti_cheat_rationale: prevents: - Tests mutating or colliding with the candidate installer state they are meant to qualify - Passing source-tree checks while the copied candidate fails under inherited user XDG configuration - Candidate validation leaving user-state artifacts behind relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Owner-authorized scheduled integration drain ```yaml test_integrity_note: change_type: [spec_correction, new_tests] scenarios: - id: SCN-scheduled-integration-drain given: A project has a reviewed periodic integration-drain schedule and a source commit with passing exact-SHA checks when: The system schedule dispatches first before and then after per-request landing authorization then: The unauthorized request stays unlanded, the authorized request lands through the FIFO integration service, and no timer is installed merely by defining the schedule observable_outcomes: - Integration drain is accepted only as a periodic, owner-authorized system mutation using configured landing authority - Sub-minute intervals and retries are rejected before scheduled execution - A request without per-item landing authorization is not drained even when the schedule itself is owner-approved - A request with fresh exact-commit check receipts lands through the same serialized integration path - Schedule configuration alone does not install or start the user-systemd timer determinism_controls: - Disposable local Git repository/worktree, fixture check receipt, manual clock, no remote, provider, real systemd executor, or runtime anti_cheat_rationale: prevents: - Turning a background schedule into blanket approval for queued code - Draining work without exact-SHA evidence or configured landing authority - Implying that review or configuration automatically activates persistent host state relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Evidence-backed organization assessment in Session Architect proposals ```yaml test_integrity_note: change_type: [new_tests, spec_completion] scenarios: - id: SCN-architect-organization-assessment given: A project has two evidenced implementation domains and a Session Architect proposal is pending when: The proposal recommends either a flat fleet or a coordination lead then: The choice is evidence-validated, proposed leads state an integrated outcome and bounded decisions, implementation and owner authority remain separate, and direct peer communication stays available observable_outcomes: - The bootstrap brief presents hierarchy evidence, all six authority distinctions, and a flat-by-default recommendation without selecting a fixed role catalog - A coordination role must cite known evidence, coordinate only existing domains, and name an integrated outcome, decision scope, and owner escalations - Duplicate or unknown domain references and fields outside the authority contract are rejected - A role that claims implementation paths or owner-approval authority is rejected - An unresolved shape, fabricated evidence, or manager-only peer routing is rejected - The proposal remains pending and no identity, organization graph, runtime, or provider is activated determinism_controls: - Temporary Git project with two local source domains and a synthetic provider response; no paid provider, runtime, or installation anti_cheat_rationale: prevents: - Copying a fixed management hierarchy into unrelated projects - Promoting relays without evidence or an integrated outcome - Smuggling code ownership or owner authority into coordination roles - Turning hierarchy into a communication bottleneck relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ## 2026-09-29 — Read-only organization lifecycle order in the owner Console ```yaml test_integrity_note: change_type: [new_tests, interface_redesign] scenarios: - id: SCN-console-readonly given: An installed Fleet with an approved reporting graph and managed identities when: The owner views the organization section in the local Console then: Startup and wind-down orders match the runtime planner, direct manager dependencies and hierarchy blockers remain visible, and observation performs no lifecycle action - id: SCN-console-lifecycle-blockers given: An installed Fleet whose valid role graph collapses into an identity-level reporting cycle when: The owner opens a fresh Console snapshot then: The lifecycle projection exposes the cycle blocker and performs no start or stop action observable_outcomes: - Startup lists managers before their reports using the same ordering function as fleet startup - Wind-down lists the exact reverse order used by fleet shutdown - The projected order includes direct manager identities and any graph blockers - An identity-level reporting cycle remains an explicit lifecycle blocker in the fresh snapshot - The lifecycle projection states mutationPerformed false and offers no start/stop controls - Narrow layouts stack the two ordered sequences without hiding identities determinism_controls: - Temporary installed Git project, deterministic organization graph, no runtime adapter invocation, timer, provider, or host service anti_cheat_rationale: prevents: - A dashboard-only order that disagrees with executable lifecycle policy - Hiding a missing manager or identity cycle behind a plausible sequence - Representing an observation preview as a session launch or shutdown relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` # Frozen queued-check input scenarios (2026-09-30) ```yaml test_integrity_note: change_type: [new_tests, refactor_tests] scenarios: - id: SCN-frozen-check-inputs given: Approved build inputs and matching project commit marker when: Source is rebuilt in place after capture then: Frozen bytes stay unchanged and only the owned copy can be removed - id: SCN-frozen-check-rejection given: Stale markers, unsafe input paths or modified copies when: Capture or verification is requested then: No qualifying snapshot is accepted - id: SCN-frozen-resource-check given: A browser slot is occupied and a specialist prepares its inputs when: The specialist commits and rebuilds before its slot becomes free then: CLI and identity-bound MCP run the captured build and receipt its original SHA - id: SCN-frozen-check-mutating-executor given: An executor changes input bytes or fails to launch when: The prepared check finishes then: Nonpassing evidence is persisted and the owned copy is cleaned up observable_outcomes: - Actual filesystem bytes, independent inodes, exact-SHA receipts and persisted prepared states - CLI approval refusal and identity-bound MCP results - Candidate acceptance rejects missing frozen-input evidence even with green command exits determinism_controls: - Disposable Git repositories and source/build fixtures - Explicit FIFO acquisition and release without waits or retries anti_cheat_rationale: prevents: - Reusing a live build directory under a frozen label - Unsafe hardlinks to mutable outputs - Crediting an old test to a newer specialist commit - Green executor exit hiding changed inputs relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` # Project-defined test-condition receipts (2026-09-30) ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-check-conditions-contract given: A real project probe reports matching subject and required conditions when: Measurements execute then: Pre/post reports validate and the diagnostic precedes measurement output - id: SCN-check-conditions-fail-closed given: False, missing, malformed or wrong-subject reports when: A check is requested then: Measurements do not execute - id: SCN-check-condition-drift given: Initially valid conditions when: A green measurement changes visibility then: The invalid postflight makes the evidence incomplete - id: SCN-condition-receipts given: Live and frozen checks with condition policy when: Check results are persisted and queried then: Valid reports persist and missing evidence or changed policy cannot qualify observable_outcomes: - Real subprocess output and absence or presence of measurement files - Durable exact-commit receipt fields, condition artifacts and pass qualification - Candidate acceptance rejects omitted condition scenario markers determinism_controls: - Fixed clock and disposable local Git/filesystem fixtures - Probe reports use independent copies of expected subject values - Policy-change checks edit canonical project configuration, not an in-memory service map anti_cheat_rationale: prevents: - Treating exit zero as proof of correct test conditions - Running measurements despite invalid preflight - Passing results despite postflight drift - Applying a report to a different build or condition policy relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` # Policy-controlled specialist self-claim (2026-09-30) ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-console-live-refresh given: Concurrent snapshot reads, edited model/task fields and an active approval preview when: Controlled 15-second refreshes and explicit owner actions run then: Reads remain single-flight, stale responses are discarded, unrelated evidence updates, draft/preview DOM survives, completing one action preserves other drafts and failures retain evidence observable_outcomes: - Deferred promise request ordering without sleeps - Real browser input values, original preview token and unprotected panel node replacement - Successive external profile changes update a clean editor without falsely marking it dirty - Pause/resume, hidden visibility and page lifecycle timer behavior - Missing scenario marker blocks candidate acceptance determinism_controls: - Explicit promise resolution for read races - Playwright clock with controlled visibility/page lifecycle events - Isolated demo transport and zero live API calls anti_cheat_rationale: prevents: - Re-rendering over owner drafts or issuing a different preview token - Allowing slow background reads to starve updates - Completing an action by clearing unrelated forms - Using real sleeps or broad retry loops to hide races relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-console-operation-outcomes given: Unknown delivery effects, interrupted operations, malformed receipts and credential-bearing arbitrary metadata when: Read-only project-scoped evidence is rendered through the shared dashboard then: Unknown and unconfirmed states stay explicit, success does not imply live deployment, arbitrary metadata is omitted, safe text is escaped and no retry buttons or state mutations appear observable_outcomes: - In-memory SQLite records unchanged after observation - Cross-project records excluded and raw secret references/error codes omitted - Real isolated browser demo renders outcome/effect uncertainty on desktop and mobile - Missing scenario marker blocks candidate acceptance determinism_controls: - Explicit SQLite fixtures and isolated demo transport - Live API calls aborted during browser tests anti_cheat_rationale: prevents: - Interpreting command success as a live release claim - Leaking raw adapter references or arbitrary error text - Retrying uncertain effects from a read-only dashboard relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` Browser review exposed a genuine mobile section-heading overflow. Production CSS now allows the title/status row to wrap; the strict document-width assertion remains unchanged. No retry, sleep, hidden overflow or tolerance was added. ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-canonical-fetch given: An installed project with a local canonical remote containing a new commit when: Owner-confirmed object import encounters one transient failure then succeeds then: Attempts are durable and bounded, exact objects arrive, refs and working tree remain unchanged, no remote publication or secret error persistence occurs - id: SCN-canonical-fetch-boundaries given: Authentication or unknown errors, invalid limits, non-owner callers and a changing canonical destination when: CLI and service fetch paths are exercised then: Missing approval or invalid callers fail, permanent errors do not retry, transient exhaustion stops at the limit, changed policy stops another attempt and read-only status reports results observable_outcomes: - Real local bare Git remote, exact object presence, unchanged refs and worktree - SQLite attempt records and actual CLI JSON/status - Missing scenario markers reject candidate acceptance determinism_controls: - Disposable local Git repositories; transport failures injected at the executor boundary - No real remote or deployment exercised anti_cheat_rationale: prevents: - Sharing fetch retry semantics with push or deploy authority - Treating authentication failure as a transient network hiccup - Updating branches through implicit fetch refmaps - Persisting credential-bearing transport errors relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` Fixture correction: local canonical creation correctly rejected an uncommitted installation, so the fixture now commits installation metadata before that gate. Production uses the existing narrow owner-audit API and adds only the named `canonical.fetch` permission; no identity or audit assertions were relaxed. ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-console-task-activity given: Old owner requests, blocked work, managed Git branches and missing history when: Activity is observed through the Console snapshot and rendered on the work board then: Owner requests sort first, metadata updates do not hide age, incomplete history remains unknown, blocked waiting is explicit, no task or Git mutation occurs observable_outcomes: - Real disposable Git history and read-only HTTP snapshot - Shared renderer escapes text, bounds lists and preserves closure as intent - Real browser demo shows owner-first activity review without live API calls - Missing scenario marker rejects candidate acceptance determinism_controls: - Fixed Git dates, explicit observation clock and disposable repositories - Isolated demo transport with all live API requests aborted anti_cheat_rationale: prevents: - Equating missing history with neglected work - Resetting inactivity through metadata edits - Mutating backlog or treating Closes text as completion relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-console-check-evidence given: Legacy and conditioned receipts, malformed frozen-input metadata and an unconfirmed running preparation when: Read-only project evidence is projected and rendered in the actual Console then: Invalid or absent evidence remains explicit, project isolation and text escaping hold, no database mutation occurs, private capture paths stay hidden observable_outcomes: - Project-scoped SQLite projection and shared escaped dashboard HTML - Real browser demo displays captured input and before/after observations - Missing scenario marker blocks candidate acceptance determinism_controls: - In-memory SQLite with explicit records and isolated demo transport - All live API calls blocked during the browser scenario anti_cheat_rationale: prevents: - Treating a running record as proof of a live executor - Treating missing conditions as independently verified runtime truth - Leaking capture paths or reading untrusted artifact paths - Escaping legacy schema support through observation-side migrations relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` Owner-briefing UI additions (2026-09-30): `SCN-console-owner-digest` tests owner-first rendering, HTML escaping, ignored raw Markdown, evidence labels, stale/future-clock/unpublished/unavailable/truncated states and no source mutation. `SCN-demo-owner-digest` uses the existing isolated demo transport to prove that an approval changes live sample state without rewriting the historical briefing or another demo workspace. Both exact markers are candidate acceptance requirements with missing-marker rejection. The real Playwright demo scenario additionally checks actual briefing DOM, immutable publication after approval, desktop/mobile screenshots, mobile anchor clearance above sticky navigation and expanded-evidence width, while all live API requests are intercepted/aborted. Reduced-motion media makes anchor-position assertions deterministic without sleeps. No previous overflow assertion was weakened: two animation frames after viewport resize allow responsive layout to settle before the existing strict width measurement. No previous assertion was relaxed; new fixtures use the actual TorchDemo factory and token confirmation fields. Screenshots prompted the mobile anchor-spacing fix. ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-owner-digest given: Owner and peer approval waits, an old owner request and implementation-only work when: A read-only report is generated and explicitly published locally then: Owner waits lead, implementation is not shipping, escaped Markdown and bounded Git coverage preserve truthful reporting, and latest publication survives reopening and CLI/API reads - id: SCN-owner-digest-schedule given: Owner-approved typed system coordination schedule and enabled digest policy when: The action runs or publication policy is revoked then: A local report is stored with no external command or AI wake and the existing scheduler respects revocation - id: SCN-owner-digest-receipts given: Seeded recorded receipts across old, current and future windows plus uncertain later deployment when: Bounded reporting and publication encounter an audit failure then: Window/count/truncation and recorded decisions remain explicit, uncertainty is not live success and publication rolls back observable_outcomes: - Immutable local report and atomic publication audit, unchanged authoritative backlog - No outbound notification, provider wake or host timer installation - Markdown escaping, read-only no-store API and method rejection - Exact missing-scenario markers block candidate acceptance determinism_controls: - Disposable Git/worktree/database fixtures with fixed clock and recorded-history seeds - Receipt seeds test reporting, not independent deployment or landing qualification - No sleep, network provider or retry used to hide failures anti_cheat_rationale: prevents: - Calling landed or implemented work shipped - Inventing management decisions from undated documents - Reporting partial history as proven neglected work - Treating a local artifact as public publication or external delivery relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` New fixture corrections use the existing scheduler's canRun result and the approval service's decidedBy argument. They do not weaken authority, revision, policy-revocation or receipt assertions. The schema refinement now explicitly permits only the owner-authorized typed owner-digest coordination action; it does not permit arbitrary command actions to claim coordination behavior. ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-delivery-attempts given: Approved delivery policy and an explicitly retry-safe adapter when: Transient failures precede success or an executor throws with uncertain effects then: Attempts persist before execution, approval remains mandatory, success advances once, unknown effects block repeats and owner recovery preserves uncertainty - id: SCN-delivery-retry-boundaries given: Bounded retry policy and independent database callers when: Failures are permanent, safety is undeclared, the limit is reached or authority changes mid-operation then: No extra external invocation occurs and changed policy is observed by a long-lived service - id: SCN-delivery-succeeded-recovery given: A durable successful adapter receipt and interrupted local application when: The owner reviews and confirms a stopped executor after reopening the control plane then: Exact saved success is applied once without an adapter, destination/authority drift blocks it and recovery-audit failure rolls back while preserving receipts observable_outcomes: - Persisted operation and attempt records, shared idempotency key, unchanged failed lifecycle state - Independent control-plane connections refuse overlapping execution - Reopened state, CLI attempts and owner-attested recovery, bounded console observation - Existing lifecycle scenario still proves real Git/check/integration gates separately - Legacy schema migration preserves receipts; parent-running/latest-success crash window is recoverable - CLI preview/approval and replay produce no extra attempts or lifecycle events determinism_controls: - Disposable local repositories and deterministic in-process project adapter outcomes - Direct fixture placement at release-ready only for retry scenarios, explicitly not release qualification - No network calls, delays, host timers or live deployment anti_cheat_rationale: prevents: - Retrying uncertain side effects or hiding failed attempts - Advancing state after a failed adapter or bypassing owner approval - Counting provider declarations as independently verified behavior - Selecting latest fixture by ambiguous timestamps - Redeploying already-successful work after a local failure - Treating unknown outcomes as saved success or asserting provider receipt truth relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` Landed-closure additions (2026-09-30): `SCN-landed-task-closure` uses real disposable Git worktrees/check receipts and proves opt-in closure after the exact canonical landing, no closure before landing, manager-only authority, wrong-owner/wrong-commit/unknown-item refusal, idempotent replay and fresh check-policy invalidation. `SCN-landed-closure-recovery` holds an actual task lock while landing, verifies durable landed state survives closure failure, revokes automatic policy, tests read-only CLI preview and missing-approval refusal, then explicitly retries closure without another Git landing. Identity-bound MCP refuses specialist closure and unapproved manager mutation. The existing bootstrap scenario now also requires generated specialist prompts to name task IDs, treat trailers as intent and confirm landed/completed state; these are additive assertions, not proof that a live model follows the prompt. Both exact scenario markers are now required by candidate acceptance, including negative missing-marker tests. No assertions were relaxed. Initial fixture filename corrected from nonexistent project.json to actual tracked torch.yaml; production source-area lookup uses the actual config.domains schema. These tests do not qualify a live fleet or independently verify model behavior. Commit-activity additions (2026-09-30): new tests only; no existing assertion was removed or relaxed. Real disposable Git histories with fixed commit dates exercise `SCN-backlog-commit-activity` (linked progress, owner-first neglect, unchanged task state and clean working tree), `SCN-backlog-activity-coverage` (bounded/missing history produces unknown, future commits cannot fake current progress), and `SCN-commit-closure-intent` (only standalone trailers describe intent, without executing text or completing tasks). Current-source candidate acceptance requires all three exact scenario tokens; missing evidence fails even when test commands exit green. Commit metadata is not implementation proof. Automatic closure, host scheduling and live dashboard activity are not claimed by these scenarios. ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-backlog-self-claim given: Default-disabled policy and explicitly routed ready work when: The owner permits one specialist and it resolves work then: Priority-ordered claims are audited to the specialist and existing work resumes even after revocation - id: SCN-backlog-self-claim-readiness given: Dirty work, guards, prepared checks, resource waits, approvals or integration when: The specialist requests its next assignment then: Work remains ready and concrete blockers are returned - id: SCN-backlog-self-claim-race given: Two local specialist processes and two ready tasks when: Both request work concurrently then: Exactly one task is assigned and the other call resumes or fails closed on contention - id: SCN-cli-backlog-self-claim given: Approved policy and a bound specialist when: CLI previews or confirms and MCP attempts another identity then: Preview preserves task revision, confirmation claims once, identity spoofing is rejected - id: SCN-backlog-blocked-resume-serialization given: One blocked task and a different active task owned by the same specialist when: The blocked task is resumed then: It remains blocked until the other active assignment ends observable_outcomes: - Tracked task JSON, revisions, state and specialist-attributed history/audit - Actual concurrent child processes, CLI JSON and identity-bound MCP responses - No assignment-only message generated for a self-claim - Exact marker verification rejects missing scenarios even when longer IDs share their prefix determinism_controls: - Disposable Git repositories and explicit persisted policy changes - Real project-scoped locks; lock contention is a fail-closed outcome, not a retry anti_cheat_rationale: prevents: - Bypassing assignment authority via a public selfClaim field - Granting work outside explicit routing or with incomplete dependencies - Claiming a second task after restart or blocked-task reactivation - Reading policy only once before the owner revokes it relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` # Provider update preflight (2026-09-30) Self-host packaging follow-up: extended the existing SCN-candidate-isolation fixture with a tracked `.torch/torch.yaml`; assert it is absent from the engine candidate while committed engine files and dependency symlinks remain present. This adds a stricter no-project-state-shipping invariant without changing any existing assertion. Update policy is validated under `runtimes..updatePolicy`, which older readers already treat as extensible runtime data; no incompatible top-level project key or permanent global provider setting is introduced. ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-provider-updates given: approved selected built-in providers and deterministic registry when: latest versions install and pass parser/version smoke checks then: registry launches exact managed binaries and fresh startup is offline - id: SCN-provider-update-cli given: installed project with owner-enabled update policy when: dry run, actual startup and failed stale refresh execute then: preview is offline, actual launch uses updated binary, failure cannot launch - id: SCN-provider-updates-recovery given: prior verified activation when: download fails, another updater owns lock or executable changes then: prior selection survives failure and unsafe or concurrent use is refused - id: SCN-provider-update-safety given: fixed official package allowlist and owned prefixes when: arbitrary name, injected version, escaped prefix or symlink store appears then: updater refuses without arbitrary install execution observable_outcomes: - persisted selected versions and exact launch commands - refusal codes and absence of downloads during preview or fresh-cache use determinism_controls: - isolated XDG roots, local Git fixtures and boundary installer runner - no provider accounts or live registry in regression tests anti_cheat_rationale: prevents: [unverified activation, global overwrite, silent stale fallback, arbitrary command injection] relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` # Setup and canonical worktree briefs (2026-09-30) ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-guided-setup given: "An approved installed project with uncommitted TORCH files" when: "Owner reviews and authorizes setup" then: "Only owned files are committed; registered worktrees exist; no providers start; staged user work blocks setup" - id: SCN-worktree-canonical-brief given: "A registered worktree has older instructions" when: "Its installation root is resolved and a brief requested" then: "Canonical instructions appear; unregistered worktrees, copied installs and stale installation IDs fail closed" - id: SCN-install-restore given: "A normally detached project retains configuration and worktree commits" when: "Owner explicitly restores the install" then: "Binding is reattached without changing profiles, worktree history or launching providers" observable_outcomes: - "Git commits, clean canonical checkout, worktree registrations, brief text and local detach metadata" determinism_controls: - "Isolated temporary Git repositories and XDG state; no provider or network calls" anti_cheat_rationale: prevents: - "Hard-coded success without Git worktrees or commits" - "Accepting copied or unregistered installation state" - "Staging unrelated owner work" relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ``` # First live scheduler pilot: native systemd parser (2026-09-30) ```yaml test_integrity_note: change_type: new_tests scenarios: - id: SCN-systemd-native-unit given: "A generated dispatcher with a repository path containing spaces, percent and quote characters" when: "The real Linux systemd-analyze parser verifies the emitted service" then: "The service parses successfully and WorkingDirectory remains an absolute scalar path" observable_outcomes: - "Actual native parser exit status and generated unit bytes" determinism_controls: - "Temporary project path alias and unit file; /usr/bin/true command; verify-only, no service activation" anti_cheat_rationale: prevents: - "Mocked systemctl success masking invalid unit syntax" - "Treating quoted ExecStart syntax as valid for scalar WorkingDirectory" relaxation: did_relax_any_assertion: false if_true_explain_spec_basis: "" ```