AiWingman: A Local Continuity Overlay for Codex Task Portfolios with Retrospective Specification-Conformance Testing of Its Policy Layer

1. Introduction

Coding-agent work is often organized as a portfolio rather than a single conversation. A user may delegate several tasks, answer one agent’s question, and leave another task waiting on an external event. The user may then receive a result in a third task and later resume work when the original plan is no longer clear. The newest timestamp is not necessarily the next useful task. Conversely, age and silence do not establish that work is obsolete or abandoned.

Prior work establishes programmer task context and resumption [1,2,3,4], awareness dashboards and personalized triage [5,6], agent-development and observability interfaces [7,8,9,10,11], and human oversight of multi-agent activity [12,13]. More recent trajectory and debugging systems add event replay, steering, annotation, and coding-agent visual analytics [14,15,16,17,18,19]. Current GitHub Copilot documentation describes parallel agent sessions, progress and token inspection, session-history queries, summaries, cost guidance, task resumption, deep links, and a separate critique agent [20,21,22]. Official OpenAI documentation describes related product surfaces. These include ChatGPT desktop Activity and goal workflows and comparable workflows in Codex clients. They also include code review across ChatGPT and Codex and a Codex App Server interface for conversation history and streamed events [23,24,25,26]. These product-family precedents rule out first-of-kind claims for task portfolios, continuity, status display, session recall, review, token visibility, or agent-assisted critique. This article makes no superiority claim because it reports no direct comparative evaluation.

AiWingman provides a narrower, implementation-specific design case. Its unofficial retrospective policy layer combines locally retained Codex task evidence, an offline-default ordinary dashboard, explicit and reversible user-owned lifecycle decisions, and deterministic ranking suppression under written evidence rules. The direct SQLite and deep-link adapter is an unsupported implementation choice and a compatibility risk, not a novelty claim. Each constituent idea has prior art. The contribution is their auditable integration and the preparation of a versioned source and evaluation package.

AiWingman is not a coding agent, an autonomous project manager, an official OpenAI product, or a stable Codex integration. It observes local behavior that is not documented as a public compatibility contract. It writes AiWingman-owned preferences and continuity metadata but is not a write-free application. Its optional remote review is not part of the offline ordinary dashboard.

This article makes four bounded contributions:

• It documents two distinct implementation pipelines without attributing task-tree aggregation or graph analysis to the ordinary dashboard.
• It specifies a deterministic continuity policy that separates observed evidence from reversible lifecycle decisions and can return no recommendation under explicit conditions.
• It reports a participant-free, specification-based evaluation of the pure policy layer. The evaluation includes exact conformance, within-process repeatability, a five-sentinel non-propagation check, a confirmed-state invariant, and descriptive-performance results. Technical-baseline comparisons are labeled post-freeze exploratory contrasts. Later fresh-process and cross-architecture checks are identified as post-freeze supplementary evidence.
• It provides a claim ledger that distinguishes historical release engineering evidence, current policy evidence, and reader, interface, remote, security, compatibility, and human-outcome questions outside the reported frozen policy benchmark.

Contributions 1 and 2 are source-backed system and policy descriptions. The frozen experiment evaluates only the pure policy layer in contribution 3; it does not evaluate either reader, the interface, the optional remote review, or human outcomes. Contribution 4 is an audit artifact rather than outcome evidence.

The reported evaluation recruited no participants and used no surveys, interviews, private task histories, or human-outcome measurements. The article does not claim faster resumption, improved recall, lower workload, better decisions, fewer wasted tokens, or increased productivity.

2. Related Work and Positioning

2.1. Programmer Task Context and Resumption

Kersten and Murphy’s Mylar work captured task context, filtered development artifacts by degree of interest, and restored context across task switches [1]. Parnin and DeLine investigated cues for resuming interrupted programming tasks through a survey and controlled study [2]. Parnin and Rugaber characterized resumption behavior across a large set of programming sessions [3]. These studies make generic task-context restoration and programming-resumption novelty untenable. They motivate AiWingman’s checkpoints, next actions, and continuity cues, but they do not validate those features for coding-agent portfolios.

Research on user-authored source annotations also shows how developers use externalized cues for reminding and refinding [4]. AiWingman’s next actions, waiting conditions, and lifecycle labels serve a related design function. Their usefulness in this product remains unmeasured.

2.2. Awareness Dashboards and Triage

Developer-awareness dashboards and feeds predate AiWingman [5]. Personalized issue-tracking views have likewise been studied as a way to reduce information overload [6]. These systems establish awareness and portfolio triage as prior concepts. AiWingman’s policy is evaluated for agreement with its own frozen specification, not for relevance to a person’s real work and not against these systems as a human-performance comparator.

2.3. Multi-Agent Interfaces, Oversight, and Observability

AutoGen Studio provides interfaces for building, running, evaluating, and debugging multi-agent workflows [7]. AgentScope, AgentBoard, and AgentOps offer multi-agent development, evaluation, monitoring, or observability abstractions [8,9,10]. AgentTrace proposes runtime instrumentation and structured operational, cognitive, and contextual traces [11]. AiWingman does not define or instrument an agent runtime; it retrospectively reads evidence retained by a local client.

Kitano et al. describe a dashboard for asynchronous review and human oversight of coordinating research agents [12]. Dhanorkar et al. identify a priori control, co-planning, real-time monitoring, and post-hoc review in interviews with experienced developers [13]. These studies are direct precedents for catch-up and oversight across agent activity. AiWingman’s optional review is an implementation feature, not evidence that oversight quality improves. The Kitano workshop paper is cited by its workshop-hosted uniform resource locator (URL). Its displayed digital object identifier (DOI) is a placeholder and is not treated as valid.

Recent trajectory interfaces further narrow the contribution boundary. ReDel supports event-based logging and interactive replay [14]. AGDebugger combines a message-history overview with interactive reset and steering [15]. Agent Trajectory Explorer supports trajectory visualization, annotation, and human feedback [16]. Coding-agent-specific visual analytics compare code evolution, solution processes, and model behavior [17]. AgentDiagnose and Graph of Trace provide structured trajectory inspection and visualization [18,19]. These systems primarily support runtime or post-hoc analysis of trajectories. They do not establish the usefulness of AiWingman’s cross-session lifecycle decisions or deterministic ranking suppression.

Within the targeted primary-source comparison set reviewed on 23 August 2026, GitHub Copilot showed substantial documented overlap across several examined capabilities. This comparison was not a systematic review, does not rank all products, and does not establish novelty. Official Copilot documentation describes monitoring parallel sessions and viewing logs, tokens, and session information. It also covers archiving, sharing, resuming, and querying sessions; producing stand-up summaries; suggesting cost or instruction improvements; opening app deep links; and invoking a separate Rubber Duck critic [20,21,22].

Official OpenAI documentation is an even closer product-family precedent. It describes a ChatGPT desktop Activity view for unread, running, or waiting chats. The documented labels include Running, Needs input, Ready, and Blocked [23]. Goal workflows support pause, resume, parallel chats, and status recaps across ChatGPT desktop and Codex clients [24]. The Codex App Server supports stored-thread listing, status and history reads, archive and unarchive operations, and thread token-usage events [25]. OpenAI documentation also describes code review across ChatGPT and Codex, including a dedicated Codex reviewer and review pane [26]. These product surfaces rule out feature-firstness for task portfolios, continuity, status display, review, or token visibility in this product family. AiWingman is therefore framed as a third-party retrospective policy case. It combines locally retained Codex evidence, reversible user-owned lifecycle metadata, and frozen deterministic ranking-suppression rules. Its direct database and deep-link integration is a compatibility risk rather than a novelty contribution.

2.4. Local-First Design and Deterministic Ranking Suppression

Local-first software emphasizes user control and continued operation without a service dependency [27]. Privacy engineering guidance treats data minimization, user participation, and transparency about collection and use as relevant design considerations [28]. AiWingman’s ordinary dashboard adopts these as design principles; they are not inventions or privacy proofs. The optional remote path is excluded from the offline-default claim.

Classical reject-option and selective-classification research formalizes risk-error or risk-coverage relationships for predictors [29,30]. AiWingman is not a learned predictor, has no confidence calibration, and provides no statistical guarantee. It instead uses deterministic ranking suppression: fixed rules return no recommendation when eligible evidence is absent, the top score is below a threshold, or top candidates are too close. The term does not imply statistical selective prediction.

3. System Scope and Two Separate Pipelines

AiWingman is a native Swift application whose package declares a macOS 13 deployment target. The reported builds and tests ran on later macOS versions. No real macOS 13 launch or runtime result is reported. SwiftUI and AppKit provide the menu-bar interface. The source package separates reusable policy and reader components from the application interface, diagnostics, and self-tests. Selected executable, bundle, preference, and application-support identifiers retain the earlier Activity Radar name so upgrades preserve existing user-owned state.

The implementation has two distinct evidence pipelines. They share selected types and presentation surfaces, but they do not perform the same aggregation.

Pipeline	Input and reduction	Outputs and permitted claims
Ordinary dashboard	The CodexActivityReader queries candidate rows that are non-archived, have a nonempty preview, are absent from retained child-edge identifiers, and have a thread_source value of user, empty, or null. It reduces each selected candidate’s own bounded rollout evidence and does not aggregate descendant rollouts into the root.	Per-candidate attention and continuity cues, explicit lifecycle controls, and a user-selected local deep link back to Codex. The observed-schema filters do not prove user ownership or complete root classification.
Optional Wingman analysis/review	The separate CodexWingmanEvidenceReader resolves parent-child task trees, scans bounded root and descendant rollout tails, and derives tree-level descriptive evidence.	Tree summaries, descriptive graph/theme signals, a maximum cumulative token-counter comparison proxy, and construction of a bounded packet for an optional consented command-line interface (CLI) request.

Figure 1. AiWingman’s two pipelines and trust boundaries. The upper ordinary-dashboard path is local and per-candidate-row. The lower optional Wingman path constructs task trees and may cross a remote boundary only after packet preview and one-shot consent. The policy benchmark reported in this article evaluates neither reader nor the remote path.

Figure 1. AiWingman’s two pipelines and trust boundaries. The upper ordinary-dashboard path is local and per-candidate-row. The lower optional Wingman path constructs task trees and may cross a remote boundary only after packet preview and one-shot consent. The policy benchmark reported in this article evaluates neither reader nor the remote path.

3.1. Ordinary Dashboard

The ordinary path opens the local Codex SQLite database with SQLITE_OPEN_READONLY and PRAGMA query_only=ON. It queries candidate rows that are non-archived, have a nonempty preview, and are not listed as children in retained spawn relationships. Eligible rows have a thread_source value of user, empty, or null. The requested base page and total returned set are each capped at 200 rows. Priority and active, blocked, or limited goal-linked inclusions are deduplicated and capped at 64. The inclusion scan takes at most 200 rows from a reverse-rowid goal window. It orders eligible records from that window by updated_at_ms. The scan reports a conservative hasMore condition when the goal window or selected inclusions are truncated. It then fetches goal metadata only for the bounded returned identifiers. This is a finite compatibility window, not a guarantee that every retained goal is represented. Ordinary SQLite text is subject to per-field and aggregate byte ceilings before Swift string copying. These observed-schema filters do not prove user ownership or complete root classification. Each selected row’s rollout is sampled within fixed bounds. The evidence is reduced to a local observation, such as explicit input requested, unseen final result, blocked, recently active, quiet open work, or incomplete history. The dashboard combines these observations with AiWingman-owned continuity metadata and applies the pure policy layer described in Section 4.

These SQLite controls prevent AiWingman from issuing Structured Query Language (SQL) statements that modify database content. They do not establish filesystem immutability. For a write-ahead-log-mode database, a read-only open is possible under three documented conditions [31]. The -wal and -shm files may already exist and be readable; the containing directory may be writable so SQLite can create them; or the database may be opened as immutable. Read-only SQL access therefore does not by itself establish filesystem immutability.

The ordinary dashboard may request that macOS open a user-selected task through a codex://threads/<thread-id> deep link. The implementation accepts only the standard hyphenated universally unique identifier (UUID) layout and normalizes hexadecimal case. It constructs the identifier as one URL path segment. Before handoff, it rejects delimiters, traversal syntax, braces, alternate layouts, and encoded separators. A successful NSWorkspace.open return establishes only that macOS accepted the open request. AiWingman does not observe whether Codex displayed the requested task. The route is based on observed local behavior rather than a documented stable application programming interface (API). Unsupported schemas, absent files, unreadable evidence, or invalid identifiers are intended to fail neutrally instead of causing a source-state migration.

The current revision requires a standardized lexical descendant of the configured Codex root and opens each path component relative to that root with no-follow semantics. It rejects symbolic-link components and non-regular or untrusted files and bounds the session-index tail read. The SQLite adapter canonicalizes the parent path and requests a no-follow final open. These are property-specific implementation controls. They do not establish that every local input is safe or that the whole application is sandboxed. Reader robustness is outside the policy benchmark reported in Section 5 and Section 6.

3.2. Optional Wingman Analysis and Review

The optional reader constructs a parent-child forest from retained spawn relationships, identifies roots and descendants, and samples bounded rollout tails across the tree. Duplicate edges are not intended to multiply evidence, and cycles or structurally inconsistent graphs are treated as compatibility failures. The tree reader is not used to make the ordinary dashboard’s per-candidate-row continuity observation.

Spawned rollouts may share a cumulative token-counter lineage. Summing all counters in a tree can therefore double count shared history. The Wingman pipeline uses the largest observed cumulative counter in a tree as a tree-level cumulative comparison proxy. It is not a billed-token total, a period-specific quantity, a cost, a measure of usefulness, or a measure of waste. A date filter selects trees by recent activity; it does not turn a lifetime counter into usage during that date interval.

Text similarity, weighted degree, PageRank, and connected components are descriptive summaries of retained tree evidence. They are not measures of success, scientific interest, personality, cognitive load, or causal importance. They have no result in the frozen policy evaluation and are not part of the article’s core empirical claim.

3.3. User-Owned State

Interface language, date range, and lifecycle choices are stored separately from Codex state. Continuity records pseudonymize task identifiers and are bounded by record and per-task history counts; the optional research ledger is additionally bounded by age and event count. The application therefore reads Codex state through adapters while writing its own state. It does not repair or migrate the Codex database.

4. Continuity Policy and Confirmation Contract

The frozen policy layer receives normalized observations and optional user-authored continuity metadata. It does not open databases, parse rollout files, construct graphs, invoke a model, or navigate the interface.

4.1. Precedence and Deterministic Scoring

Policy evaluation follows four stages:

• Apply absolute deferrals.
• Exclude an eligible item if its history is incomplete.
• Derive ordered, fixed-vocabulary reason codes that contain no raw task text, together with integer weights.
• Sort eligible candidates and apply deterministic ranking-suppression rules.

A future snooze is deferred as snoozed; a non-empty waiting condition is deferred as waitingOnExternal. Terminal work is also deferred when the frozen terminal conditions hold and no direct attention signal, near deadline, or due snooze overrides that state. Deferred items are not scored.

An incomplete, non-deferred item is excluded from scoring. Its presence does not suppress a recommendation supported by another complete item. If no candidate remains and an eligible incomplete item was observed, the policy returns incompleteHistory and exposes no ranking.

Table 1. gives the normative reason order and weights. The order is part of serialized output.

Order	Condition	Reason code	Weight
1	Explicit input requested	explicitInput	100
1	Blocked goal	goalBlocked	90
1	Unseen final result	unseenResult	80
1	Usage limited	usageLimited	70
1	Budget limited	budgetLimited	70
2	Deadline due or overdue	deadlineOverdue	65
2	Deadline within one day	deadlineWithinDay	55
2	Deadline within three days	deadlineWithinThreeDays	40
2	Deadline within seven days	deadlineWithinWeek	20
3	Planned return is due and no later accepted open request exists	plannedReturnDue	45
4	Critical importance	criticalImportance	30
4	High importance	highImportance	20
4	Low importance	lowImportance	-10
5	Non-empty next action	nextActionRecorded	10
5	No plan and age 7 to less than 30 days	agingWithoutPlan	12
5	No plan and age at least 30 days	agingWithoutPlan	18
6	Recently active execution	recentlyActive	8
7	An open request was accepted by macOS between 0 and 15 minutes ago, inclusive	recentlyOpened	-15

Table 1. gives the normative reason order and weights. The order is part of serialized output.

Order	Condition	Reason code	Weight
1	Explicit input requested	explicitInput	100
1	Blocked goal	goalBlocked	90
1	Unseen final result	unseenResult	80
1	Usage limited	usageLimited	70
1	Budget limited	budgetLimited	70
2	Deadline due or overdue	deadlineOverdue	65
2	Deadline within one day	deadlineWithinDay	55
2	Deadline within three days	deadlineWithinThreeDays	40
2	Deadline within seven days	deadlineWithinWeek	20
3	Planned return is due and no later accepted open request exists	plannedReturnDue	45
4	Critical importance	criticalImportance	30
4	High importance	highImportance	20
4	Low importance	lowImportance	-10
5	Non-empty next action	nextActionRecorded	10
5	No plan and age 7 to less than 30 days	agingWithoutPlan	12
5	No plan and age at least 30 days	agingWithoutPlan	18
6	Recently active execution	recentlyActive	8
7	An open request was accepted by macOS between 0 and 15 minutes ago, inclusive	recentlyOpened	-15

Candidates are sorted by descending score and then ascending activity identifier. A recommendation requires a score of at least 30 and, when a runner-up exists, a lead of at least 10. A top score below 30 returns insufficient Evidence; an existing runner-up less than 10 points behind returns competing Signals. When the policy returns no recommendation, it exposes no ranked candidates. A result with no candidates distinguishes incomplete History, no Eligible Work, and insufficient Evidence according to the frozen precedence.

The weights and the 30-point score and 10-point lead thresholds are author-designed constants inherited from the pre-existing implementation. They were not optimized against empirical user data, derived from participants, or calibrated as probabilities, confidence values, risks, or utilities. The frozen fixtures test their written behavior; they do not validate that these constants are appropriate for people.

Figure 2. Frozen continuity-policy flow. Future snooze, waiting, and terminal rules defer an item. Incomplete eligible history excludes that item. The policy scores the remaining complete items. It suppresses the ranking when the top score is below 30 or, when a runner-up exists, the lead is below 10. An incomplete item does not suppress a recommendation from another complete item.

Figure 2. Frozen continuity-policy flow. Future snooze, waiting, and terminal rules defer an item. Incomplete eligible history excludes that item. The policy scores the remaining complete items. It suppresses the ranking when the top score is below 30 or, when a runner-up exists, the lead is below 10. An incomplete item does not suppress a recommendation from another complete item.

4.2. Lifecycle States

Observed evidence and lifecycle decisions are separate. A user confirmation is authoritative and maps directly to its reversible lifecycle state. Only explicit abandoned or obsolete confirmations can produce abandonedConfirmed or obsoleteConfirmed.

Without confirmation, the policy maps direct attention to waitingHuman, blocked, or current. It maps an external waiting condition to waitingExternal. Future snoozes, paused work, and sufficiently old quiet work map to dormant; completed work maps to completed; and missing or unknown evidence maps to uncertain. Age can add inactive-evidence codes, but silence, age, and an aborted turn cannot infer a confirmed obsolete or abandoned state.

4.3. Optional Remote-Review Boundary

The dashboard starts no background agent request. Opening the Wingman view also does not invoke the Codex CLI. A separate, explicit compatibility check validates the signed executable. It runs version, command-compatibility, and login-status checks. The check starts no agent turn and sends no AiWingman task packet. However, it creates a private temporary Codex home with an opaque copy of the validated saved authentication file. The packet-carrying Wingman request is triggered separately. Before one-shot consent, the interface makes the intended user-derived packet available in a collapsed disclosure control. The implementation verifies byte equality between that packet and the current preview. It does not require the user to expand the control. The packet builder intentionally omits raw task identifiers, raw paths, configuration files, tool outputs, and authentication-file contents. The detailed portion can include sanitized titles for up to 12 task-tree rows. Counts and aggregates represent selected trees outside those detailed rows. Sanitized prompt excerpts may be included only after an explicit opt-in. Human-authored continuity text is excluded. With prompt content disabled, task-derived free text is limited to sanitized titles. The packet omits prompt excerpts, prompt-derived themes, local review signals, and next-move text. It still carries timestamps and the activity cutoff, status and enumeration fields, booleans, counts, numeric measurements, schema and response-language metadata, and a fixed method-boundary string.

Sanitization is best-effort and cannot prove removal of every secret, especially a secret embedded in a title or allowed text. User inspection of the preview remains necessary. Unexpected CLI JSON Lines (JSONL) items or tool events invalidate the returned review. Invalidation does not prove that the child process performed no earlier filesystem read, network exchange, or tool attempt. The child read-only mode is not an operating-system sandbox for the application.

The CLI is invoked with --ephemeral, which requests a turn intended not to save a local rollout. This option does not prove that no local artifact exists and does not define service-side retention. The compatibility probe and review use private temporary roots. Their names begin with the exact prefixes ActivityRadar-CLI-Probe- and ActivityRadar-Wingman-, respectively. A process-wide gate permits only one such remote operation at a time. Normal completion and error paths attempt removal and verify absence. If absence cannot be verified, the result is rejected and the unresolved root is latched. Later remote operations in the same application process retry cleanup and remain blocked while cleanup fails. A crash or forced termination can bypass that path and leave a prefixed directory. Restarting the application does not itself prove that residue was removed. These are implementation controls outside the frozen policy benchmark. They do not prove security isolation or complete credential removal under every failure mode.

The ordinary dashboard contains no intended network path in the evaluated source architecture. Source-level checks for network APIs are bounded static evidence, not runtime non-interference. The optional CLI path intentionally reaches an external service after consent.

5. Evaluation Method

5.1. Scope and Research Questions

The evaluation covers only WorkContinuityRanker and WorkContinuityLifecycle. It excludes both readers, Codex database and rollout compatibility, graph analysis, token proxies, interface behavior, deep links, diagnostics, and local storage. It also excludes optional CLI execution, remote output, and user outcomes.

The study asks four research questions (RQs). RQ3 was formulated after the protocol and corpus freeze. It is reported only as a post-freeze exploratory technical contrast:

• RQ1, conformance: Does the Swift policy match every expected output in the frozen synthetic corpus?
• RQ2, repeatability and bounded output checks: Do 100 within-process evaluations of each fixture yield one canonical output; that is, do evaluations 2-100 match evaluation 1? Do the five exact seeded sentinels remain absent from the scanned serialized output surface? Do unconfirmed fixtures remain free of confirmed-obsolete or confirmed-abandoned states?
• RQ3, post-freeze exploratory technical comparisons: How often do two deliberately simplified rules produce the same selected identifier as the frozen policy? How often do they select an item when the frozen policy requires no recommendation?
• RQ4, descriptive performance: What latency distribution is observed for synthetic portfolios of 10, 50, 200, and 1,000 inputs? What single process-lifetime peak resident-memory value is observed after the full runner workload?

5.2. Freeze and Chronology

The evaluation artifacts have a staged repository chronology in which the written specification and expected outputs were committed before the archived benchmark execution. The policy implementation already existed before this freeze, which was not a preregistration. Repository chronology and the author’s account do not attest that no earlier exploratory or unarchived execution occurred.

Stage	Content-addressed checkpoint	Role
Historical superseded source release	5e212181ae177cd555ab6bb92f5f71ac8be9173a, tag v1.2.0-beta.2	Historical product and continuous-integration (CI) evidence; not the policy-result commit and not recommended for use
Protocol freeze	53aa3e28862ff76092ad83d1347635fb1209a17d	Written specification, Python generator, 155-fixture corpus, and freeze manifest; committed after policy implementation but before the archived benchmark execution
Swift runner	fa5186e5d04fedfd75daac72e533a1daf9dbfa89	Standalone benchmark executable; clean detached-worktree execution is author-reported rather than machine-attested by the result files
Result package	e46686588793173d1b299b1829a92dbab7e9528d	arm64 summary report plus the post-freeze 100-process supplementary script and summary

The specification SHA-256 is ee6ab6568a3fcf8332facf9ef0a2d3bae66ab15d7f09a63ca6cbef6c-e44e6f11. The corpus SHA-256 is 183025163326aeb7f95470d2ecf494b31bc8239c8abb3e74e939967cf3-ad8f30, and the Python generator SHA-256 is 2c27f2bd7950e0aa26b8878ae27e13dfcd3332571f32-b61444feb1111a8aae3c. The freeze manifest records 75 triage fixtures and 80 lifecycle fixtures, for 155 total.

The evaluated policy source, Sources/ActivityRadarCore/WorkContinuity.swift, has SHA-256 ff68e565bb1cebff47d66a23488e84b4e7bc2bf39cf8b75740683a7a055fa895 at the historical release, protocol-freeze, runner, result, and hardened-source checkpoints. Repository ancestry and these hashes show that the same source bytes were already present at the earlier release checkpoint and remained unchanged through the reported exact-commit CI checkpoint.

The author reports building and running the Swift checkpoint from a clean detached worktree. The first-version (V1) result package does not independently attest that procedure. The fresh-process driver’s --runner-commit value is operator supplied. The driver does not compare that value with Git HEAD, require a clean worktree, or record the built executable’s hash. The checkpoint association is therefore a provenance boundary. Section 9 specifies revision, worktree-status, and source-hash checks for this boundary.

The Python standard-library generator does not import, invoke, parse, or copy Swift source. It implements the written specification as a separate oracle at the language boundary. However, the same project produced the specification, oracle, fixtures, and Swift implementation, and the specification and fixtures were authored after the implementation already existed. Knowledge of the implementation could therefore have shaped both the contract and its examples. This is a same-project, retrospectively specified, separately implemented oracle, not an implementation-independent reference standard or external validation.

5.3. Exact-Output Checks

The Swift runner strictly decodes the corpus and checks its schema version and fixture counts. It verifies the corpus bytes against the embedded corpus hash. It also compares the corpus’s embedded specification-hash value with the value compiled into the runner. The runner does not read or hash the specification file itself; the separate shell reproduction checks in Section 9 perform that check. For triage fixtures, it compares the recommendation or no-recommendation result, candidate identifiers and order, scores, ordered reason codes, weights, evidence times, and deferrals. For lifecycle fixtures, it compares state, ordered evidence codes, evidence times, and ages. A fixture passes only if every specified field matches.

For the frozen within-process repeatability check, every fixture is evaluated 100 times. Evaluation 1 supplies that fixture’s baseline canonical output; evaluations 2-100 are compared with it. The loop therefore performs 15,500 policy evaluations and 15,345 nontrivial equality comparisons (155 fixtures multiplied by 99 comparisons). Canonical JavaScript Object Notation (JSON) uses sorted keys. One representative canonical output per fixture is framed with the frozen fixture identifier, in frozen order, to form the corpus digest. Timing, environment metadata, and expected outputs are excluded from the digest.

Post-freeze supplementary repeatability check. The frozen protocol specified the within-process repetition check but did not specify a 100-fresh-process driver. That driver and its result were added together in the result package. It launches the release benchmark 100 times. Each process checks conformance over all 155 fixtures and separately performs the runner’s 100-evaluation-per-fixture repeatability loop before returning one canonical corpus-output digest. The supplementary evidence unit is therefore the process-level digest: 100/100 processes passed and returned one unique digest. It is not an additional 15,500-evaluation denominator and is not presented as preregistered evidence.

Result-package errata. The archived cross-process JSON contains “evaluationCount”: 15500, computed by the V1 driver as 100 processes multiplied by 155 fixtures. RESULTS_MANIFEST_V1.json carries the analogous crossProcessEvaluationCount. Those labels describe process-fixture summary coverage, not individual policy-function calls. The within-process repeatability loops contain 1,550,000 policy evaluations across the 100 fresh processes. This value equals 100 processes multiplied by 155 fixtures and 100 evaluations. The loops include 1,534,500 nontrivial comparisons with per-fixture evaluation 1. These counts exclude separate conformance and performance calls. The historical contentNeutrality field name likewise denotes only the absence of five exact seeded strings from the scanned serialized output surface. This revision preserves the committed JSON files and hashes. It records both terminology defects in Research/results/RESULTS_ERRATA_V1.md and reports the narrower checks directly.

The five-sentinel non-propagation check uses five exact strings seeded in 10 field placements across nine fixtures, covering title, path, checkpoint, next-action, and waiting text. All 155 serialized conformance outputs were searched for all five strings. Outputs still contain activity identifiers, and the policy can depend on whether selected text fields are empty. The check therefore does not establish semantic content independence, anonymity, noninterference, or absence of identifiers. It also does not inspect either reader, the user interface (UI), logs outside the runner, diagnostics, preview packets, or remote requests. The confirmation-gated lifecycle invariant is checked over 70 fixtures without user confirmation; any obsoleteConfirmed or abandonedConfirmed output is a violation.

A retrospective observability audit found a narrower V1 coverage defect. When the policy returns no recommendation because of a low score or close competition, it returns no ranked candidates. Consequently, no frozen expected output exposes the triage reason/weight pairs for deadlineWithinWeek, lowImportance, either agingWithoutPlan weight, or triage recentlyActive; the V1 triage corpus also has no zero-input portfolio. Changing one of those rules while preserving the same no-recommendation outcome could therefore leave 155/155 exact-output conformance unchanged. The V1 result remains exact agreement with its frozen outputs, not evidence that every written rule output was observed.

5.4. Post-Freeze Exploratory Technical Baselines

The frozen written protocol did not specify either baseline. Both contrasts first appeared in the later Swift runner commit, after the protocol and corpus freeze. They are therefore reported as post-freeze exploratory technical contrasts, not frozen or confirmatory evaluation components, competing products, or human-quality measures.

• Recency-only always selects the input with the latest timeline activity, breaking ties by ascending identifier. It ignores deferrals, history completeness, metadata, score thresholds, and lead suppression.
• Same-score/no-suppression applies the frozen deferrals, incomplete-history exclusion, weights, sorting, and identifier tie-break, but removes the 30-point threshold and 10-point lead requirement.

For each of the 75 triage fixtures, exact decision agreement means equality of the recommended activity identifier; nil means no recommendation. A no-recommendation violation occurs when a contrast selects an identifier for a fixture whose frozen expected result exposes no recommendation. This label does not imply that every such result arises from the score threshold or lead rule: the recency-only contrast also removes deferrals and history-completeness eligibility.

5.5. Post-Freeze Rule-Observability Supplement

The frozen V1 specification, corpus, and result artifacts were not modified. Six later engineering tests use combined inputs and exact assertions. They expose the four previously hidden triage reason codes, both agingWithoutPlan weights, and the zero-input no-recommendation result. A standard-library mutation harness copies the current Swift package to a temporary directory and confirms the six focused tests. It then changes each asserted weight or empty-portfolio result individually. A mutation counts as killed only when the corresponding named test fails. This supplement is a retrospective regression check. It is not part of V1, a complete mutation analysis, exhaustive state coverage, an external oracle, or human-utility evidence.

5.6. Performance Procedure and Environment

The runner performs five warm-up calls followed by 30 measured repetitions for each input size. It reports the median, a linearly interpolated ninety-fifth percentile, the interquartile range, and the maximum using DispatchTime.uptimeNanoseconds. For each series, N denotes the input count. Triage measures one ranking call over N synthetic inputs. Lifecycle measures N assessment calls over the same synthetic inputs. The 200-input series corresponds to the current ordinary-dashboard return cap. The 1,000-input series deliberately exceeds that product limit and serves only as a synthetic policy-layer stress size. None of the series measures end-to-end dashboard latency.

The benchmark report machine-recorded arm64 architecture, macOS 26.6.2 build 25G83, 14 active processors, and release configuration. The separately authored result manifest records a MacBook Pro model Mac16,7, Apple M4 Pro, 48 GB memory, Apple Swift 6.3.3, and target arm64-apple-macosx26.0. These additional fields are author-reported rather than runner-attested. Process peak resident memory was sampled after all series using macOS getrusage (RUSAGE_SELF). It is a process-lifetime peak, not an allocation total or a per-operation measurement.

5.7. Generative Artificial Intelligence (AI) Assistance in the Research Workflow

OpenAI Codex assisted with source discovery, code inspection, literature organization, and document formatting. It also assisted with drafting and revising the specification, Python oracle, synthetic fixtures, benchmark runner, tests, and manuscript. Codex supported author-directed internal adversarial reviews of claims, methods, security boundaries, and publication artifacts. These same-project reviews were neither human nor external peer review and did not provide independent validation.

The named author is responsible for verifying every claim, reference, result, and generated artifact. The author is also responsible for revising the prose as needed and approving the final manuscript for submission. AI is not listed as an author and was not treated as an independent reviewer or validation source.

6. Results

6.1. Conformance, Repeatability, and Bounded Contract Checks

Table 2 summarizes the V1 machine-readable result report. Passing per-fixture actual outputs were not archived as rows; the artifact retains counts, failure records, and a corpus-output digest. It is therefore a summary report rather than a complete per-fixture result ledger. The primary report SHA-256 is fa7e271a436be62bf9c7f9979122ccc6a01d36fe03abaea7b4a0277472a9957e. The post-freeze fresh-process summary SHA-256 is 9d1dcd88b2dca1672ccfabee076ee2c9274ebb6345827-5b30e6a4269b37b4af1.

Check	Denominator	Result	Supported interpretation
Frozen exact-output conformance	155 fixtures	155/155 passed	Swift policy matched all same-project specification-derived expected outputs
Frozen within-process repeatability	155 fixtures × 100 evaluations	Evaluations 2-100 matched evaluation 1 for every fixture; 15,500 total evaluations and 15,345 nontrivial equality comparisons	One representative output per fixture formed one corpus digest on the recorded process and machine
Post-freeze supplementary fresh-process repeatability	100 fresh processes	100/100 passed; one unique digest	Every process produced the same 155-fixture corpus digest on one arm64 machine after its internal repetition loop
Five-sentinel non-propagation	5 exact strings; 10 field placements across 9 fixtures; all 155 outputs searched for all 5 strings	0 exact sentinel occurrences	The five seeded strings did not appear in the scanned serialized policy-output surface
Confirmation-gated lifecycle invariant	70 unconfirmed fixtures	0 confirmed-state violations	No unconfirmed fixture produced confirmed obsolete or abandoned

The canonical corpus-output digest was fd72e52b8098d2f62f6c6f7ccc6de7e744de7ed0372-2d08c7f983527601db8e6 in the primary run and all 100 supplementary fresh processes. The frozen conformance, within-process, sentinel, and lifecycle results answer RQ1 and RQ2 within the recorded arm64 environment. The fresh-process result is a later supplementary check. Neither result establishes external correctness, reader privacy, or remote-model repeatability.

6.2. Post-Freeze Rule-Observability Supplement

The machine-readable result records that all six focused tests passed in the unmodified temporary package copy. Five simple compiling weight mutations covered the four previously hidden reason codes. Separate mutations addressed the two agingWithoutPlan weights. A sixth mutation changed the empty-portfolio no-recommendation result. Each corresponding focused test failed, so 6/6 enumerated mutations were killed. The result is Research/results/post-freeze-rule-observability-v1.json; the runner is Research/run_rule_observability_mutations.py. The harness reported that it did not mutate the repository working tree. This evidence is post-freeze, same-project, narrow, and supplementary. It neither repairs the historical V1 corpus retroactively nor establishes exhaustive coverage.

6.3. Post-Freeze Exploratory Technical Baseline Comparisons

Table 3 reports the post-freeze exploratory exact-decision agreement and no-recommendation violations over all 75 triage fixtures. These contrasts were not specified in the frozen written protocol.

Technical contrast	Exact agreement with frozen decision	No-recommendation violations
Recency-only	40/75 (53.3%)	35
Same-score/no-suppression	59/75 (78.7%)	16

The recency-only rule selected an item in all 35 frozen no-recommendation cases: 18 insufficientEvidence, 12 noEligibleWork, two incompleteHistory, and three competingSignals results. Because that contrast removes deferrals, history-completeness eligibility, scoring, and both suppression rules, its 35 cases locate the combined effect of those mechanisms rather than ranking suppression alone. The same-score/no-suppression contrast selected an item in 16 cases: 13 insufficientEvidence and three competingSignals results. Those 16 isolate the mechanical effect of removing the 30-point score threshold and 10-point lead requirement while retaining deferrals, eligibility, weights, sorting, and identifier tie-breaking. Fixture categories were deliberately constructed and were not sampled or prevalence-weighted. The agreement percentages are proportions within this synthetic contract corpus, not estimates of real-world error or recommendation frequency. Neither comparison shows that the frozen policy is more useful, accurate, efficient, or preferable for people.

6.4. Descriptive Performance

Table 4 reports rounded summary statistics in milliseconds; the archived JSON retains the full recorded precision. Every cell is based on 30 measured repetitions after five warm-ups. The 1,000-input rows are synthetic policy-layer stress sizes above the ordinary dashboard’s current 200-row return cap.

Operation	Inputs	Median (ms)	95th percentile (ms)	Interquartile range (ms)	Maximum (ms)
Triage portfolio	10	0.00375	0.00386	0.000042	0.0125
Triage portfolio	50	0.0232	0.0241	0.000291	0.0396
Triage portfolio	200	0.0936	0.0948	0.000240	0.0951
Triage portfolio	1,000	0.511	0.567	0.0292	0.569
Lifecycle batch	10	0.00363	0.00369	0.000000	0.00383
Lifecycle batch	50	0.0190	0.0194	0.000115	0.0194
Lifecycle batch	200	0.0758	0.0949	0.00267	0.103
Lifecycle batch	1,000	0.388	0.425	0.0181	0.471

The process-lifetime peak resident memory after all performance series was 12,992,512 bytes, approximately 12.4 mebibytes (MiB). Because that value covers the entire runner process and all series, it cannot be attributed to a particular operation or input size. The latency and memory results are descriptive for synthetic policy inputs on one machine and cannot be converted into human time saved.

6.5. Release and Exact-Commit Engineering Evidence

GitHub Actions run 32648392604 evaluated the older public release commit 5e212181ae177cd555ab6bb92f5f71ac8be9173a on 23 August 2026. The arm64 macOS 15 and native x86_64 macOS 15 jobs each reported 52 passing Swift tests and 16 passing deterministic self-tests. The Intel job built the release application. The arm64 gate also ran enumerated source, diagnostics, storage, manifest, and local Universal 2 package checks.

This is regression and packaging evidence only for the named release commit. It is separate from the arm64 policy benchmark at fa5186e5... and does not validate the later manuscript, protocol, reader hardening, or result branch. The original mutable release-page copy and the release notes stored at commit 5e212181... contained three documentation overstatements. They implied macOS 13 runtime support without a real macOS 13 run. They also stated that the dashboard never writes under ~/.codex without accounting for the write-ahead-log -shm exception. Finally, they reduced the prompt-off preview packet to titles and numeric measurements. The unsigned annotated tag v1.2.0-beta.2 currently resolves to that commit. The release-page body was corrected on 23 August 2026 with a post-tag notice. The notes stored at the historical commit remain unchanged. Those original statements are not treated as evidence here. A successful Swift command with zero discovered tests is not counted as evidence.

The beta2 source tag is historical and is not recommended for installation. Path containment, bounded session-index reads, and verified normal/error temporary-auth cleanup first appear at later hardened checkpoints and are outside the frozen policy benchmark.

A later exact-commit GitHub Actions run, 32659669054, evaluated hardened source checkpoint 99faac3ef52d0da72d082706f64903a6aacd2c6d on 23 August 2026. The GitHub-hosted macOS 15 arm64 and native x86_64 jobs each discovered and passed 82 Swift tests. Each job also passed 16 deterministic self-tests and ran the 155-fixture benchmark. Both benchmark jobs returned 155/155 conformance and digest fd72e52b8098d2f62f6c6f7ccc6de7e744de7ed03722d08c7f983527601db8e6. The Intel job also built the release application. The arm64 job passed the public-source preparation check and a synthetic diagnostic non-disclosure fixture. The policy source at this checkpoint is byte-identical to the source at the frozen runner checkpoint.

This exact-commit run is post-freeze engineering regression evidence on two hosted architectures. It is not part of the V1 result package, an independent reproduction, a broad cross-machine or operating-system claim, or a real macOS 13 runtime result.

7. Limitations and Threats to Validity

Retrospective same-project oracle. The written specification, Python oracle, fixtures, Swift implementation, and benchmark runner were produced within the same project, and the implementation predated the specification and fixture corpus. Language-boundary separation prevents direct source import but does not prevent knowledge of existing behavior from shaping the contract. Confirmation bias and shared misunderstandings can therefore survive 155/155 conformance.

Synthetic and finite coverage. The 155 fixtures instantiate a finite set of frozen expected outputs, not every state combination or every independently observable rule output. Because a no-recommendation result hides ranked candidates, V1 does not expose deadlineWithinWeek, lowImportance, either agingWithoutPlan weight, or triage recentlyActive, and it has no zero-input portfolio. The later six-test, six-mutation supplement closes only those enumerated observability gaps and is not retroactive V1 evidence or exhaustive mutation coverage. The non-propagation check covers five exact sentinels and only the scanned serialized policy-output surface. Outputs retain activity identifiers, and the policy can use text-field emptiness. The check is not semantic content independence, anonymity, general noninterference, privacy, or a secret-removal proof.

Policy-only scope. Neither Codex reader, graph construction, token proxy, UI, deep link, local storage, diagnostics, preview, child process, or remote response is part of the reported benchmark. Reader and remote-boundary tests must be reported separately and must not be added to the 155-fixture denominator.

Unreported gates. No separately frozen metamorphic ledger, complete adversarial reader ledger, or end-to-end remote disclosure ledger is reported in the V1 result package. Current-branch dual-architecture CI is reported separately as post-freeze engineering evidence. Unit tests and that CI run cannot be substituted for an omitted frozen ledger.

Core result and supplementary architecture scope. The frozen result and the 100-fresh-process supplementary check ran on one arm64 Mac. A later exact-commit CI run matched conformance and the digest on one hosted arm64 and one hosted x86_64 runner. That post-freeze run supports equality for those two jobs only; it is not external reproduction or broad cross-machine, compiler, or operating-system determinism.

Post-freeze exploratory baselines. The baselines were added after the protocol and corpus freeze and deliberately remove policy mechanisms. The 35 recency-only violations combine deferral, eligibility, scoring, threshold, and lead effects; only the 16 same-score/no-suppression violations isolate removal of the threshold and lead rules. These mechanical contrasts provide no external reference standard, user preference, or comparative superiority. The deliberately constructed fixture corpus is not a prevalence sample, so the agreement percentages are not real-world frequency estimates.

Performance scope. Timings use synthetic normalized inputs and exclude database input/output (I/O), rollout parsing, interface rendering, graph analysis, and remote calls. The 1,000-input case is above the current ordinary-dashboard return cap and is only a stress size. The process-level memory peak is not isolated by series. No independent process rerun, randomized series order, thermal or central processing unit (CPU) frequency control, or confidence interval was reported. Each reported ninety-fifth percentile is a descriptive linearly interpolated quantile of 30 observations.

Undocumented integration and SQLite boundary. AiWingman depends on observed Codex filenames, SQLite schemas, JSONL events, and deep-link routes that may change. Read-only/query-only opening prevents application SQL writes to database content. SQLite documents three conditions for opening a write-ahead-log-mode database as read-only [31]. The -wal and -shm files may already exist and be readable; the containing directory may be writable so SQLite can create them; or the database may be opened as immutable. Neutral failure and logical read-only access cannot establish filesystem immutability or create a stable third-party API contract.

Token and graph interpretation. The optional tree maximum is a cumulative comparison proxy. It is neither period usage nor billed, useful, or wasted tokens. Graph summaries are descriptive and unevaluated.

Remote and security boundary. Packet minimization, preview, opt-in, event rejection, path checks, serialized temporary-auth use, and verified normal/error cleanup are narrow controls. Best-effort sanitization cannot guarantee secret removal. Output rejection does not prove the absence of prior I/O. A crash can leave a temporary root before cleanup or latch handling completes. The application is not claimed to be security-isolated, and no external security audit is reported.

No human-outcome evidence. No participants or private task histories were studied. The article cannot answer whether AiWingman improves recall, resumption time, workload, decision quality, productivity, or token use.

Archival and independence boundary. Hardened source checkpoint 99faac3... is publicly reachable, and exact-commit run 32659669054 supplies bounded hosted CI evidence for that checkpoint. The V1 artifacts are versioned in the same project, but no independent scholarly reproduction or independent archival verification is reported. A later preprint DOI would document manuscript deposit, not validate the source, methods, or results.

8. Discussion

The evaluation supports a narrow conclusion. The pre-existing Swift continuity policy matched every expected output from a same-project synthetic specification committed before the archived benchmark execution. Across the frozen within-process repetitions, each fixture matched its first canonical output. Five exact seeded strings were absent from the scanned serialized output surface. The tested lifecycle fixtures also respected the explicit-confirmation boundary. Repository chronology does not exclude earlier exploratory or unarchived runs. A post-freeze fresh-process check and later dual-architecture CI returned the same digest within their stated environments. None of these checks establishes whether the policy chooses the right task for a person.

The V1 corpus does not expose every triage reason or the zero-input boundary. The later observability supplement makes the four hidden reason codes, both aging weights, and the empty-portfolio result explicit, and kills six corresponding simple mutations. This is useful current-branch regression evidence, but it does not alter the historical 155-fixture result or establish exhaustive coverage.

The post-freeze exploratory baseline results locate distinct mechanical effects. A pure recency rule selected an item in all 35 frozen no-recommendation cases while removing deferrals, eligibility, scoring, and suppression. Retaining the frozen score but removing only the threshold and lead rules selected an item in 16. The latter shows that the two ranking-suppression rules change synthetic contract decisions. Neither contrast establishes calibrated uncertainty or improved decisions.

The product-level design contribution is likewise integrative. Task context, reminders, dashboards, post-hoc oversight, and agent-session summaries are established. AiWingman combines selected versions of these ideas around locally retained Codex evidence. It preserves three distinctions: ordinary per-candidate-row inspection versus optional task-tree analysis; observed evidence versus user-owned lifecycle confirmation; and offline-default local analysis versus a previewed, consented remote request.

Further evidence should remain finite and claim-driven. The native x86_64 CI result closes only the bounded equality check for the named hosted jobs. Independent cross-machine reproduction would address same-project and hosted-environment bias. Frozen adversarial ledgers for both readers and the temporary remote boundary would address only enumerated path, graph, disclosure, event, and cleanup properties. A later human study would require a new protocol and would be necessary before any efficacy claim.

9. Reproducibility and Availability

The public source repository is available at: https://github.com/mehmetsolakedu/activity-radar

The historical source tag and CI record are:

• Release v1.2.0-beta.2: https://github.com/mehmetsolakedu/activity-radar/releases/tag/v1.2.0-beta.2
• GitHub Actions run 32648392604: https://github.com/mehmetsolakedu/activity-radar/actions/runs/32648392604

The protocol, runner, result, erratum, hardening, and manuscript source are maintained on branch codex/aiwingman-technical-preprint. The exact software checkpoint evaluated by the cited CI run is 99faac3...; later manuscript-package commits do not retroactively become evidence from that run: https://github.com/mehmetsolakedu/activity-radar/tree/codex/aiwingman-technical-preprint

The latest evaluated source checkpoint represented in the current evidence package is 99faac3ef52d0da72d082706f64903a6aacd2c6d, with exact-commit CI record:

https://github.com/mehmetsolakedu/activity-radar/actions/runs/32659669054

These content-addressed Git commits establish repository identity, not independent archival preservation. The manuscript source and generated documents may receive later content-only revisions before deposit. No preprint DOI or archival release is claimed.

Reproduction should begin from a separate detached worktree at the exact runner revision:

The git rev-parse HEAD command must report fa5186e5d04fedfd75daac72e533a1daf9dbfa89, and git status --porcelain must produce no output. The expected SHA-256 values are:

• Package.swift: 03389531d1cd8aea9222e2663a603b89fbacbba1fa48e4813d2e415dae107425
• Sources/ActivityRadarCore/WorkContinuity.swift: ff68e565bb1cebff47d66a23488e84b4e7bc2bf39cf8b75740683a7a055fa895
• Sources/AiWingmanResearchBenchmark/main.swift: 068f085273f8a7638c7a0e05d13b32f0f39cc3ed519bd2327b4ef5551417906b
• Research/protocol/SPECIFICATION_V1.md: ee6ab6568a3fcf8332facf9ef0a2d3bae66ab15d7f09a63ca6cbef6ce44e6f11
• Research/generate_continuity_corpus.py: 2c27f2bd7950e0aa26b8878ae27e13dfcd3332571f32b61444feb1111a8aae3c
• Research/fixtures/continuity-policy-corpus-v1.json: 183025163326aeb7f95470d2ecf494b31bc8239c8abb3e74e939967cf3ad8f30

These checks establish source identity before building. The V1 result files themselves did not attest executable provenance.

The separate Python oracle can regenerate the frozen expected-output corpus for a byte comparison without overwriting the committed fixture:

Successful regeneration must be byte-identical and report SHA-256 183025163326aeb7f95470d2ecf494b31bc8239c8abb3e74e939967cf3ad8f30. This verifies deterministic corpus generation from the named same-project oracle and specification; it does not convert that oracle into an external reference standard.

The primary benchmark command is:

The post-freeze fresh-process driver first appears at result-package commit e46686588793173d1b299b1829a92dbab7e9528d, not at the runner revision. Add a second detached worktree, verify that driver, and invoke it against the executable and corpus in the clean runner worktree. The --runner-commit argument becomes operator-supplied metadata in the supplementary summary; it does not attest the executable’s provenance:

The second git rev-parse HEAD command must report e46686588793173d1b299b1829a92dbab7e9528d, its status output must be empty, and the driver SHA-256 must be fffcc2390d0b75a48c424bda6414055a00f06f50cb54e7ad61150f5b5f1b9070.

The reproduction target is 155/155 exact conformance and canonical corpus digest fd72e52b8098d2f62f6c6f7ccc6de7e744de7ed03722d08c7f983527601db8e6. The optional post-freeze supplementary target is 100/100 fresh processes returning that digest. A new full-report JSON is not expected to reproduce the archived report SHA-256. Timestamps, performance measurements, and per-run report hashes can differ. The archived result-manifest hashes establish byte equality relative to the committed manifest; they do not authenticate execution or prove provenance.

The repository includes versioned citation metadata in keeping with software-citation principles [32]. Software source, tests, scripts, and executable tooling are MIT-licensed. Effective 24 August 2026, the manuscript and identified non-executable research artifacts are licensed under the Creative Commons Attribution (CC BY) 4.0 International license. The specific artifacts are listed in paper/LICENSE_STATUS.md and include generated scholarly outputs, the written research protocol, synthetic fixture corpus, result data, manifests, summaries, and errata. Private Codex databases, rollout files, task text, local paths, credentials, real-work screenshots, and third-party works are outside the publication package and license grant.

Manuscript Artifact Build

The submission-manuscript build environment used Python 3.12.13 with the package versions pinned in paper/requirements.txt. A clean environment can build the editable Word manuscript and author-rendered reference document in Portable Document Format (PDF) as follows:

The PDF builder selects macOS Times New Roman and Arial when available. Otherwise, it uses the bundled ReportLab Vera faces. The Microsoft Word Open XML document (DOCX) declares Calibri for document text. It rasterizes its two generated diagrams with Arial or the same Vera fallback. Word or LibreOffice version, installed fonts, PDF metadata, and ZIP timestamps can change bytes or pagination. Therefore, byte-identical manuscript regeneration is not claimed across environments. Before upload, the final deposit bytes must be rendered page by page, scanned structurally and for compressed private content, and identified by SHA-256 values.

10. Claim Ledger

Claim	Status in this revision	Exact boundary
AiWingman is an open-source Codex-specific retrospective overlay	Supported as a project description	Third-party community software; not an official OpenAI product or stable API integration
Ordinary dashboard and optional Wingman use separate readers	Supported by source architecture	Ordinary path is per-candidate-row; tree aggregation and graph signals belong only to Wingman
Codex source state is queried through logical read-only adapters	Implementation property under engineering review	No application SQL write to database content. Write-ahead-log-mode opening may depend on readable -wal/-shm files, a writable containing directory, or immutable mode. The application writes its own state.
Pure Swift continuity policy conforms to the frozen corpus	155/155 passed on recorded arm64 environment	Exact agreement with the finite same-project expected outputs; four triage reason/weight rules and the zero-input boundary are not exposed in the frozen first-version corpus
Post-freeze focused tests expose the enumerated first-version observability gaps	The machine-readable result records 6/6 focused tests passed and 6/6 corresponding mutations killed on arm64	Same-project supplementary regression only; not part of the frozen first-version package, exhaustive coverage, or human-utility evidence
Local policy output is repeatable	Across 100 evaluations per fixture, evaluations 2-100 matched evaluation 1 (15,500 evaluations; 15,345 nontrivial comparisons); 100/100 post-freeze fresh processes returned the same corpus digest	Fresh-process check was supplementary; archived evaluationCount is an erratum, not a function-call denominator; core result is one arm64 machine; excludes readers, the user interface, graphs, and remote output
Five exact seeded strings did not propagate to the scanned policy output surface	Zero occurrences for five sentinels over 155 scanned outputs	Historical contentNeutrality label is an erratum; outputs retain identifiers; not semantic independence, anonymity, privacy, noninterference, or secret-removal proof
Confirmed obsolete/abandoned requires user confirmation	Zero violations over 70 unconfirmed fixtures	Synthetic lifecycle contract only; not an audit of every application path
Technical contrasts change frozen no-recommendation decisions	Recency-only selected an item in 35 cases; same-score/no-suppression selected one in 16	Recency-only also removes deferrals and eligibility; only the 16-case contrast isolates threshold and lead removal; no quality or superiority inference
Observed median policy latency was sub-millisecond at 1,000 synthetic inputs on the measured Mac	Median 0.511 ms triage and 0.388 ms lifecycle	Normalized synthetic policy inputs on one named environment only
Historical dual-architecture release regression evidence	52 tests and 16 self-tests passed per architecture at 5e212181...	Older release commit; not current policy-result or revision branch
Wingman tree token quantity measures exact cost or waste	Not supported	Maximum cumulative tree counter is only a comparison proxy
Graph signals measure importance or success	Not supported	Descriptive and unevaluated
Runner revision and clean-worktree provenance are machine-attested by the first-version results	Not supported	Clean detached execution is author-reported; reproduction must verify the Git HEAD revision, empty status, and source hashes before building
Optional remote review is security-isolated, residue-free under crashes, or sole-context	Not supported	Preview, a process-wide gate, two bounded temporary prefixes, and verified normal/error cleanup narrow intended disclosure; they do not prove isolation, crash cleanup, or service retention
Human efficacy or productivity benefit	Untested	No participants or outcome measures
Comparative superiority or first-of-kind status	Not claimed	Prior research and current products provide overlapping capabilities
Hardened-source hosted arm64/x86_64 policy equality and public-source preparation check	Passed at 99faac3..., run 32659669054	Post-freeze engineering evidence for the named jobs; not external reproduction, broad determinism, independent archiving, a signed public release, or macOS 13 runtime evidence

11. Declarations

Ethics and data statement. This article describes software architecture and a synthetic engineering evaluation. The reported evaluation used only synthetic fixtures. It recruited no participants and did not export or analyze private task histories as research data. It involved no animal, plant, survey, or interview data. No human-outcome inference is made.

Funding. This research received no external funding.

Author contribution. Mehmet Solak conceived the product direction and study and defined the intended use and policy. He directed and reviewed the iterative development of the software and research package. He verified the reported claims, references, results, and artifacts. He also wrote and revised the manuscript with the disclosed AI assistance. Mehmet Solak is the sole author and accepts full responsibility for the work.

AI assistance. OpenAI Codex assisted with source discovery, code inspection, literature organization, and document formatting. It also assisted with drafting and revising the specification, Python oracle, synthetic fixtures, benchmark runner, tests, and manuscript. Codex supported author-directed internal adversarial reviews of claims, methods, security boundaries, and publication artifacts. Those same-project reviews were not human or external peer review and did not provide independent validation. The named author has reviewed and verified every claim, reference, result, and generated artifact. The author revised the prose as needed and accepts full responsibility. AI is not listed as an author.

Software and research-package licenses. Executable software source, tests, scripts, build tooling, and research drivers are distributed under the MIT License. Effective 24 August 2026, the identified non-executable research artifacts are distributed under Creative Commons Attribution 4.0 International. These artifacts include the manuscript, generated scholarly outputs, written research protocol, synthetic fixture corpus, result data, manifests, summaries, and errata listed in paper/LICENSE_STATUS.md. The author confirms the right to grant both license scopes.

Identity and correspondence. The named author confirms the public name form “Mehmet Solak” and ownership of ORCID 0000-0002-0800-0334. The author also confirms the Siirt University Biosystems Engineering affiliation and mehmetsolak@siirt.edu.tr as the correspondence address. The same identity appears in the manuscript, document metadata, submission metadata, and citation file.

Corresponding-author responsibility. Mehmet Solak accepts responsibility for answering questions or comments about the preprint and for providing the reported data or materials when reasonably requested and legally permitted.