Skip to content

Instructions For Codex

rayswaynl edited this page Jun 2, 2026 · 60 revisions

Instructions for Codex

Claude-owned handoff (2026-06-02). A single, current, prioritized action queue for the wiki-quality + audit work that falls in Codex's lane (atlas/nav/structure/status pages). Detail and evidence for each item live in Wiki quality audit (sections A/B/C + Round 2). Claude-lane items are already done. Work top-to-bottom; check items off in place. Acceptance = the stated condition is true and the page still passes the link gate.

Already done (no action)

  • ✅ Nav: all 5 new Claude pages are wired into _Sidebar.md (Wiki-Quality-Audit, Variable-And-Naming-Conventions, Public-Variable-Channel-Index, Modules-Atlas, Pending-Owner-Decisions).
  • ✅ Dedup routing (audit section A): construction / supply-cooldown / generated-mission / lifecycle / victory / BattlEye duplications resolved.
  • ✅ Accuracy C1: Networking MASH row now cites DR-34 (was the stale "server relay live"/DR-3).

P0 — Accuracy (a reader is currently being misinformed)

  1. Fix the UI-atlas finding mislabels (Client UI systems atlas line ~254 "Buy-gear authority" row, and the same in Client UI HUD and menus). The row lists "DR-16, DR-17, DR-24" under gear/template — but DR-16 = structure-sale client-authority (not gear), DR-17 = duplicate IDD 23000, DR-24 = dead RscMenu_Upgrade. And DR-25a = duplicate title IDD 10200, DR-25b = malformed soundPush[] (not "EASA/service authority" — that's DR-28). Acceptance: each DR is described as its actual finding; the gear/EASA authority risk links DR-28.
  2. De-hedge the MASH status in SQF atlas — replace "MASH marker status requires careful source verification" with a definitive DR-34 cite (dead both ends). Acceptance: no "requires verification" hedge for MASH.
  3. Mark the compile counts point-in-time in SQF atlas — the "659/452/207" numbers need a timestamp + regeneration command + DR-5 cite (DR-5 warned they go stale). Acceptance: counts labelled point-in-time with how to regenerate.

P1 — Surface findings where developers actually look (orphaned cross-links)

  1. DR-44 (wfbe_supply_temp_<side> forgery) → add to Economy synthesis table, Networking direct-channel section, Server runtime atlas.
  2. DR-20 (HQ-killed N-fold score exploit) → add to Construction atlas, Gameplay atlas, Server runtime atlas.
  3. DR-45 (town-AI deletes player-occupied vehicles) → cross-link from Town-AI-Vehicle-Despawn-Safety and AI/headless.
  4. Cite DR-40 by number in WASP overlay and DR-19 in Server runtime atlas.
  5. Add the missing DR cross-links called out in audit section C2 (Gameplay atlas: DR-6/14/11/22/23/15; UI atlases: DR-16/17/24/25; AI/headless: DR-21/42; Construction atlas: DR-6; Mission entrypoints: DR-37/43a).

P1 — Reconcile "current work" status pages (they're stale)

  1. Coordination board: the "Active Lanes" + "Roles" tables are stale — sub-agent lanes (Faraday/Mencius/Hilbert/Cicero/Curie/Meitner) shown "Active" were harvested/closed in Wave F; victory-endgame-runtime-atlas shown "Active" is integrated; the Roles line says "Claude's latest reviews are DR-11..DR-15" but Claude is at DR-45 and in collaboration-follow mode. Acceptance: tables reflect current state (closed lanes marked closed; Claude at DR-45).
  2. Progress dashboard: the "At A Glance" Claude row predates Phase-1 completion + the collaboration-follow operating mode; update to reflect that the coverage ledger's Map/Perf/JIP-HC columns are complete and only Auth/PV owner-decisions remain.
  3. _Sidebar.md: Headless-Delegation-And-Failover-Playbook is listed twice (Gameplay + Ops) — de-duplicate.

P2 — Structure (page merges, audit section B)

  1. Merge Hardening roadmap + Server authority map (~70% overlap) — Migration-Map's Authority Principles + Handler Validation Checklist as preamble, Roadmap's work packages as body.
  2. Reduce Client UI HUD and menus to a quick-ref/redirect into Client UI systems atlas (it is a strict subset).
  3. Trim Mission entrypointsLifecycle wait-chain overlap (~50%): keep the description.ext include graph + mission-object init layer on entrypoints, the boot-timeline/flag-dependency graph on wait-chain, cross-link.

P3 — Thin citations (lower priority)

  1. Add representative path:line anchors to Core systems index, Architecture overview, Content structure and maps.

Do NOT change (audit false positives — verified at source)

  • Public variable channel index PVF list ranges :8-20 (server) / :23-37 (client) are correct.
  • DR-15's _side = _this at Server_AssignNewCommander.sqf:3 is correct. (An audit pass miscounted blank lines; leave both as-is.)

Not Codex's lane — informational

  • The economy/forgery owner decision (server-authority vs BattlEye, two surfaces) and the coverage-gap next-review queue (Server/AI respawn+orders, cleaners Perf, config data model, PR#1 delta) are in Pending owner decisions and Deep-review findings Round 36 — for the owner / the next review phase, not a Codex doc task.

New findings — document + cross-link (2026-06-02, Claude)

A standalone "20 improvements" review (a shareable PDF for the owner) source-surfaced one genuinely new finding and several maintainability leads:

  1. DR-46 — SEND_MESSAGE second call compile RCE (Deep-review findings). Cross-link it from Networking, Public variable channel index (the SEND_MESSAGE row) and SQF atlas (the call-compile inventory). Also correct DR-1's "no other network-data compile sites" note (≈ line 159) to acknowledge the SEND_MESSAGE direct-PV surface — the repo has two network-data compile RCE surfaces, not one. Acceptance: DR-46 is reachable from the three atlas/index pages and DR-1 no longer implies a single compile site. Fix shape: agent-hardening-backlog.jsonl#send-message-call-compile-rce.
  2. Maintainability leads — verify, then document only if not already owned by Variable and naming conventions / SQF atlas: Init_Common.sqf double-compiles ~15 fns under both GetX and WFBE_CO_FNC_GetX (plus ~22 un-prefixed in Init_Server.sqf, four GetClosestEntity{,2,3,4} variants); the Client_Support*, Construction_*Site and Loadout_* copy-paste families; ~12 hardcoded English hints bypassing stringtable.xml. Acceptance: each lead is either cross-referenced to its existing owner page or recorded as a new maintainability note.
  3. DR-30 correction (BattlEye) — drop remoteexec.txt from the missing-filters list (it is Arma 3-only; A2 OA has no remoteExec), name the A2 OA filter set instead, and reframe BattlEye as contingent, local-filter defense-in-depth (BE's online support for A2 is defunct; Client/FSM/updateclient.sqf:153-162 kickAFK is the evidence filters are processed locally). Propagate to External integrations (BattlEye section) and any "missing filters" list; DR-30's "no filters shipped" substance stands. Acceptance: no page lists remoteexec.txt as a missing A2 filter, and BattlEye is framed as defense-in-depth behind server-authority. Detail in Deep-review findings "DR-30 correction".

Batch-4 consistency findings — document / correct (2026-06-02, Claude)

Read-only wiki↔source audit of 7 playbook/index pages (~190 claims, 29 confirmed, all re-verified at source). Attack-wave authority playbook passed clean (0/8). Ordered by severity:

  1. Supply-mission authority cleanup playbook — HIGH: documents code that does not exist in current source. It reads like a draft "PR #1" written up as the shipped state. Nonexistent in source: (a) a Killed event handler on the supply vehicle — 0 grep hits for addEventHandler/Killed anywhere under Server|Client/Module/supplyMission/ (the page's Step 4 + findings-table both describe one at :10-25 and warn it "can stack"); (b) a SupplyByHeli object var — 0 grep hits across the whole mission (Step 3 + Step 7 claim it is stamped + read); (c) a heavy-heli cash-run + commander-team-funds completion branch (Step 7) — supplyMissionCompleted.sqf (36 ln) reads only SupplyAmount/SupplyFromTown and calls only ChangeSideSupply:26 (supply only, no funds path); (d) recommended-patch item 4 cites constants WFBE_C_SUPPLY_TRUCK_TYPES/WFBE_C_SUPPLY_HELI_TYPES_T2/_T3 that don't exist — truck types are hardcoded inline at supplyMissionStart.sqf:18 and Skill_Apply.sqf:72. Also the status table marks the scan "Source/Vanilla patched", but supplyMissionStarted.sqf:28 is still nearestObjects [..., [], 80] (empty filter — DR-39 not applied), and the page contradicts itself (Step 5 correctly shows []). Acceptance: the page is either clearly labelled a proposed/not-yet-applied PR, or each step is corrected to current source; the scan status is no longer "patched"; nonexistent vars/constants are removed.

    Correction (batch 6, 2026-06-02): "does not exist in current source" was imprecise. The Killed EH (a), SupplyByHeli (b), the heavy-heli cash-run + commander-funds branch (c) and the WFBE_C_SUPPLY_*_TYPES constants (d) are real code on PR #1 (feat/supply-helicopter, open, head 1faf738d) — they are unmerged, not nonexistent (verified against the PR branch + the Current-Work-Supply-Helicopters-PR1 page, which documents them accurately). So the right fix is PR-vs-master scoping (a clear "this describes PR #1, not master" banner + per-claim status), not deletion. The scan-narrowing portion is the exception: it is on no branch (master and PR1 both use nearestObjects [...,[],80]), so that one is genuinely a proposed-only fix. See item 30.

  2. ICBM authority playbook — MEDIUM: a normative line reads as a factual status. "Client Tactical-menu checks are affordances; server-side validation remains the authority boundary" implies server validation exists. It does not: Server_HandleSpecial.sqf:97-112 takes _side/_base/_target/_playerTeam from the request, logs, then only if (isNull _target || !alive _target) exitWith {} and spawns NukeDammage — no commander/upgrade/funds check (fully client-authoritative, DR-27). Acceptance: reword to normative ("should remain") and link DR-27 inline.

  3. Function and module index — MEDIUM + LOW. (MED) Common/Module/Reaktiv is listed "Live" but Reaktiv_Init.sqf has zero callers outside its own folder (never compiled in Init_Common.sqf; contrast IRS at Init_Common.sqf:320) → dead/unreachable. (LOW family-summary drift) Common_Get* lists "depots" but the depot getter is Client_GetClosestDepot (Client family, Init_Client.sqf:102); Common_Set* lists "waypoints" (no waypoint setter exists; closest is SetTeamMovePos); Common_Handle* lists "damage" (no Common_HandleDamage); Server_AI_Com_Upgrade is written WFBE_C_UPGRADES_%SIDE_AI_ORDER but source uses Format ["WFBE_C_UPGRADES_%1_AI_ORDER", _side] (a grep for %SIDE finds nothing). Acceptance: Reaktiv marked dead; the four family/name descriptions corrected.

  4. PVF dispatch implementation playbook — MEDIUM + LOW. (MED) the client-command enumeration lists 9 names as if complete, but _clientCommandPV (Init_PublicVariables.sqf:25-41) has 14 active entries — missing AwardBountyPlayer, ChangeScore, SetTask, SetMHQLock, Available. The fix code uses forEach _clientCommandPV so the patch is fine, but a reader hand-building an allowlist from the prose would drop 5 channels. (LOW) off-by-one ranges: compile loops :43-50:43-51; Common_SendToServer/…Optimized :12-17:12-18; …SendToClient :13-20:13-21; …SendToClients :12-18:12-19; and supplyMissionCompletedMessage.sqf RequestChangeScore cited :32 but it's :22 (file is 24 ln). The call compile RCE mechanism + fix-snippet SQF (A2-OA-valid) are correct. Acceptance: client list enumerates all 14 (or hedges like the server list); ranges corrected.

  5. Economy authority first cut — MEDIUM. Same SupplyByHeli ghost var (supplyMissionStart.sqf:34-46 cited; var doesn't exist; SupplyFromTown is :20, not in range). "Rewards funds/supply at :31-40" — only supply is rewarded (ChangeSideSupply:26); no funds path in supplyMissionCompleted.sqf (0 grep for ChangePlayerFunds/ChangeTeamFunds). Acceptance: drop SupplyByHeli; correct the reward description to supply-only.

  6. Variable and naming conventions — LOW. WFBE_CO_FNC_LogContent is presented as compiled in Init_Common.sqf but its definition site is initJIPCompatible.sqf:37; ≥4 other WFBE_CO_FNC_* are compiled in Init_Server.sqf (InitAFKkickHandler:63, LogGameEnd:64/89, DelegateAITownHeadless:99, DelegateAIStaticDefenceHeadless:100) — the prefix isn't exclusively an Init_Common family. wfbe_funds is set on group objects (Init_Server.sqf:474, Common_ChangeTeamFunds.sqf:8), not the logic/side/town/building objects the row implies. The wfbe_* row's lead example "queu" (Client_BuildUnit.sqf:172) doesn't carry the wfbe_ prefix. Acceptance: soften "compiled in Init_Common" to "mostly", note the group-object case, swap the queu example.

  7. Batch-2 recovery → owning pages (5 still-live items lost to a shared-worktree clobber of commit 89f848f; all re-verified at source today). Routing to the owning pages rather than re-adding a section to the findings page (your call on that page's shape):

    • Modules atlas: (:18) the incomingMissile EH at Client_BuildUnit.sqf:342 spawns HandleATMissiles (generic AT), not IRS — only :356 spawns WFBE_CO_MOD_IRS_OnIncomingMissile. (:21) the aircraft CM-removal block is gated if !(WF_A2_Vanilla) at Client_BuildUnit.sqf:275 → it runs on OA, so "Vanilla-only by design" beside the removal ref is misleading (the CM module is vanilla-gated at Init_Client.sqf:590; the removal is the non-vanilla path). (:41) Soldier skill is ceil(1.5 × …) (Skill_Init.sqf:49) — 1.5×, not "double team size". (:47) CIPHER_Sort is an ExecVM'd script (Labels_Upgrades.sqf:127Common\Module\CIPHER\CIPHER_Sort.sqf), not a compiled utility fn; the compiled CIPHER fns are CIPHER_SortArray/CIPHER_SortArrayIndex (CIPHER_Init.sqf:58,94).
    • Economy towns and supply (:30): "player delivery funds use WFBE_C_PLAYERS_SUPPLY_TRUCKS_DELIVERY_FUNDS_COEF" — that constant (Init_CommonConstants.sqf:268, =4) has zero consumers; the award passes raw _supplyAmount to ChangePlayerFunds (supplyMissionCompletedMessage.sqf:13). Dead constant.

Batch-5 consistency findings — document / correct (2026-06-02, Claude)

4 pages, 133 claims, 4 confirmed (all re-verified at source). Headless delegation and failover playbook auditor returned 0 claims (a whiff, not a clean pass) — re-audited in batch 6.

  1. Core systems index — HIGH: an external component listed as an in-mission operational system. The "Administrative/Operational Systems" line ends "…and Discord bot status publishing", bundled with genuine in-mission systems (anti-stack, AFK-kick via BattlEye publicvariable filter, server-FPS publication, performance-audit logs, global-game-stats extension export). No Discord publishing code exists in the mission — only plain-text mentions (Init_Client.sqf:959 community-link hint, briefing.sqf, stringtable.xml). The mission's actual role is the already-listed "global game stats extension export"; Discord publishing is the separate DiscordBot/ repo component that consumes that export. Acceptance: drop "Discord bot status publishing" from the in-mission list, or relabel it an external DiscordBot/ integration.

  2. Factory and purchase systems atlas — HIGH + MED. (HIGH) the table labels WFBE_C_TOWNS_PURCHASE_RANGE (60) the "depot purchase range" for updateavailableactions.fsm, but the FSM's depotInRange gate (:194) uses _tcr = WFBE_C_TOWNS_CAPTURE_RANGE (40, read at :39; constant Init_CommonConstants.sqf:323). PURCHASE_RANGE (60, :338) is used only by GUI_Menu_BuyUnits.sqf for the factory dropdown — different constant, different default, tighter gate than the page implies. (MED, DR-33b) line 219's "Current source/Vanilla Client_BuildUnit.sqf:167-172 uses a UID/player/counter token" is wrong — it is still _unique = varQueu where varQueu = random(10)+random(100)+random(1000) (:167-168, init Init_Common.sqf:164, comment "to remove with new sys later on"). Random token, fix not applied. Acceptance: correct the FSM depot-range row to CAPTURE_RANGE (40); reframe the token row as still-random (DR-33b open).

  3. Architecture overview — LOW. initJIPCompatible.sqf:31 is described as logging "player count"; it logs WF_MAXPLAYERS with the label "Max players Defined" — a mission-slot ceiling, not a live connected-player count. Acceptance: reword to "max player slots".

Batch-6 consistency findings — document / correct (2026-06-02, Claude)

9 pages, 193 claims, 18 confirmed (all source-verified). Clean: Headless delegation and failover playbook (0/6, the batch-5 whiff is resolved), Current-Work-Supply-Helicopters-PR1 (0/24 — accurately documents PR #1), Resistance supply scaffold (0/6). Town-AI vehicle despawn safety returned 0 claims (a whiff) — re-queued for batch 7.

  1. CROSS-CUTTING — HIGH: a "claimed-patched-but-unmerged" status drift across remediation pages. Several pages mark DR-19 (FPS publisher !isDedicated early-exit) and DR-39 (supply-scan nearestObjects class-narrowing) as "source/Vanilla patched" / "current source", but both are implemented on no branch. Verified branch landscape (git ls-remote origin): only master, feat/supply-helicopter (PR #1, open, 1faf738d), docs/developer-wiki-claude, docs/developer-wiki-index. PR #1 adds supply helicopters but does not narrow the scan. Recommendation: adopt a consistent Status convention — Shipped (master) / Proposed (PR #N) / Proposed (no branch yet) — and purge the false "patched/current source" labels. Affected: items 31–33 + item 19.

  2. Hosted-server FPS loop sleep — HIGH (×5). Page status "source/Vanilla patched" + its table + validation all claim both FPS publishers exitWith {} on !isDedicated. Source: neither serverFpsGUI.sqf (12 ln) nor monitorServerFPS.sqf (8 ln) has any exitWith/!isDedicated — both are still while {true} do { if (isDedicated) then { …; sleep 8 } } with the sleep reachable only inside the dedicated branch, i.e. the exact DR-19 busy-spin, unfixed. Confirmed on both Chernarus and the generated Vanilla Takistan copies (0 grep hits for exitWith/!isDedicated). Acceptance: mark DR-19 Proposed (no branch); correct the publisher descriptions to the real while{true} / inside-isDedicated shape (dedicated servers are unaffected — listen/hosted only).

  3. Supply-mission scan narrowing — HIGH + MED + LOW. (HIGH) status "patched", claiming the narrowed nearestObjects [..., ["Base_WarfareBUAVterminal"], 80] — but supplyMissionStarted.sqf:28 uses [] on both master and PR #1 (PR1 line 45), with the isKindOf "Base_WarfareBUAVterminal" check inside the forEach; the narrowed form is on no branch. (MED naming) line 17 cites Common/Config/*/Config_Structures.sqf — no such file; actual is Common/Config/Core_Structures/Structures_*.sqf. (LOW line-drift) :18:20, :42:25, :45:28, :61:44. Acceptance: mark DR-39 Proposed (no branch); fix the config path + line refs.

  4. Performance opportunity sweep — HIGH (incl. self-contradiction). (HIGH) the Notes section claims DR-19 FPS-exit + DR-39 narrowed scan are "source/Vanilla patched"/"current source" — both unimplemented — while the same page's table row (line 11) and validation (line 80) correctly say the scan is still broad [] → internal contradiction. (HIGH cross-page) validation line 94 says Skill_Init at :547 then Apply at :571, but Init_Client.sqf:571 is the second Skill_Init call (the duplicate-init perf issue) and WFBE_SK_FNC_Apply is :572 — the bullet omits the double-init and misplaces Apply, contradicting line 86. (MED) P1 row line 11 cites supplyMissionStarted.sqf:42-45 for the 80 m scan; it's :24-28 (:42-45 is the 8 m player scan). (LOW) P2 row line 13 queue decrement :471-473:467-469. Acceptance: reconcile Notes vs table (DR-19/39 Proposed); fix the Skill_Init double-init description + line refs.

  5. Supply-mission architecture — LOW. Line 75 names the broken AI logistics path AI_UpdateSupplyTruck; the compiled global is UpdateSupplyTruck (Init_Server.sqf:36 commented, spawned :383) — AI_ is only the filename, and line 65 of the same page uses the correct name. Acceptance: use UpdateSupplyTruck at line 75.

  6. Client-UI HUD and menus — LOW. GUI_Menu.sqf main Warfare menu cited at Dialogs.hpp:1025; the WF_Menu class is :1019, idd = 11000 :1021, onLoadGUI_Menu.sqf :1022 (same drift batch 3 flagged for this page). Acceptance: cite :1019-1022.

Batch-7 consistency findings — document / correct (2026-06-02, Claude)

9 pages, 174 claims, 22 confirmed. Clean: UI-IDD collision repair (0/11), WASP marker wait cleanup (0/18), Arma-2-OA compatibility audit (0/21 — A2/A3 command attributions correct), Town-AI vehicle despawn safety (a redirect stub, no checkable claims — correctly clean, not a whiff).

  1. ESCALATION of item 30 — the "patched-but-unmerged" status drift is SYSTEMIC. The Status field source/Vanilla patched is a definitive done-claim in this wiki's convention (e.g. Client-Skill-Init-Idempotency:5 + validation criteria listed as passing), not a TODO. It is false on 8 DR-remediation pages whose fixes are not in master (verified vs Chernarus and Vanilla Takistan; no fix branches exist): Hosted-Server-FPS-Loop-Sleep (DR-19), Supply-Mission-Scan-Narrowing (DR-39), Performance-Opportunity-Sweep (DR-19/39), Supply-Mission-Authority-Cleanup-Playbook (PR1/DR-39), Client-Skill-Init-Idempotency, Commander-Reassignment-Call-Shape (DR-15), Factory-Queue-Counter-Token-Cleanup (DR-33), Paratrooper-Marker-Revival (DR-2). A reader/agent trusting Status would believe ≈8 live bugs are fixed — this is the single highest-value editorial reconciliation for the wiki, and likely warrants the owner's attention. Likely cause: the pages document the intended post-patch state and were marked "patched" before the source edits landed. Recommendation: relabel every such page Proposed / patch-ready (NOT in master), or land the actual patches — never leave "patched" on a bug still live in master.

  2. Client skill init idempotency — HIGH. Status "source/Vanilla patched"; lines 5/23/33/49 assert the 2nd Skill_Init.sqf call was removed and :571 now calls WFBE_SK_FNC_Apply. Source: Init_Client.sqf:571 still compiles Skill_Init.sqf (the duplicate-init 16→24→36 compounding is live); WFBE_SK_FNC_Apply is :572. (LOW) WFBE_C_PLAYERS_AI_MAX = 16 is Init_CommonConstants.sqf:243, not :249. Acceptance: relabel Proposed; correct :571/:572.

  3. Commander reassignment call shape — HIGH. Status "source/Vanilla patched" for DR-15; claims :3 is _side = _this select 0 and the duplicate notification is gone. Source: Server_AssignNewCommander.sqf:3 is still _side = _this; (whole-array bug); both RequestNewCommander.sqf:14 and Server_AssignNewCommander.sqf:9 still send new-commander-assigned (two paths). Vanilla Takistan is identically unpatched. (LOW) Server_HandlePVF.sqf spawn is :14, not :11. Acceptance: relabel Proposed; correct the call-shape + dual-notification descriptions.

  4. Factory queue counter token cleanup — HIGH. Status "source/Vanilla patched" with "two narrow DR-33 fixes"; claims :167-168 builds a UID/player/counter token and the crewless-vehicle exit decrements the queue. Source: :167-168 is still _unique = varQueu; varQueu = random(10)+random(100)+random(1000) (init Init_Common.sqf:164, comment "to remove with new sys later on"); :365 is a bare exitWith {} with no decrement. Acceptance: relabel Proposed; correct the token + decrement claims (DR-33a/b open).

  5. Paratrooper marker revival — HIGH. Status "Source patched / smoke pending"; claims Init_PublicVariables.sqf:39 registers HandleParatrooperMarkerCreation in _clientCommandPV. Source: :39 is NukeIncoming; HandleParatrooperMarkerCreation is absent from _clientCommandPV (its only occurrence is the sender at Support_Paratroopers.sqf:117), so the PVF dispatch still fails at runtime (DR-2). Acceptance: relabel Proposed; the registration is not applied.

  6. Abandoned feature revival review — LOW (page otherwise accurate). receiverMASHmarker.sqf cited :1-28 (file ends :29); MASHMarker.sqf cited :1-11 (ends :13). The dead-feature claims themselves check out. Acceptance: minor range fixes.

Continue Reading

Detail: Wiki quality audit | Findings: Deep-review findings | Decisions: Pending owner decisions

Sidebar

Clone this wiki locally