[ten9876]

Summary

Part of #6239. The AGC-T Calibration window (AgcCalibrationDialog) moves from PersistentDialog to a CanonWindow dialog (Kind::Dialog), as the AetherRX and AetherTX Settings dialogs did:

• Chrome: no title bar, the ambient ground, the canon header and the corner close button. It closes with Esc or Ctrl+W and opens centered on the main window. It no longer follows View → Frameless Window, so showAgcCalibrationDialog() creates it directly instead of through showOrRaisePersistent().
• Title: unchanged, "AGC-T Calibration", reached as before from Tools → Calibrate AGC-T... or the AGC-T slider's right-click menu.
• Size: 460×460 (minimum 420×400), about 40 px taller to make room for the header.
• Look: it sits under the canon/agcCalibration theme scope:
  • the mode line is ink, the recommendation line cyan and the hint muted;
  • the buttons and the target field are canon controls.
• Plot: AgcCurveWidget paints from color.canon.* instead of hard-coded colors, and repaints on a theme change:
  • a nested card with a grid-colored plot frame;
  • a cyan curve with aqua points;
  • the knee marker in sparkGold, the current-value marker in ink and muted axis labels.

Close-path fix. On main, dismissing the window during an Auto Sweep (the close button, Esc or Ctrl+W) deleted the dialog, which stopped the sweep's timer but left the slice's AGC-T at whatever intermediate value the sweep had reached. Every close path reaches done(), which now stops a running sweep first. Stopping puts back the AGC-T the sweep started from, as Stop does. The destructor does the same for a dialog destroyed without a close, while the slice still exists. A sweep that has already finished is left alone, so an applied recommendation is never reverted.

Docs:

• The RX controls page says how to close the window and what closing during a sweep does.
• docs/style/* list AGC-T Calibration among the canon windows.
• The touchpoint manifest counts one more core/ThemeManager.h includer (ui-support, no radio state).
• Stale screenshot, to recapture after merge: rx-agc-calibration.png shows the old window.

Constitution principle honored

Principle VIII (Evidence Over Assertion) covers the checks below. The visual direction is RFC #6226's.

Test plan

• Local build passes
• Driven offscreen with scratch settings on the demo simulator (DEMO-0001, transmitting: false), opened via Calibrate AGC-T.... Captures show the canon header, the plot idle, mid-sweep, and finished with the gold knee marker.
• Close path: AGC-T was 65 before an Auto Sweep and 44 mid-sweep. After the bridge's close on the window it read 65, and 65 again three seconds later. The bridge cannot send an Esc key, but close reaches done() through QDialog::closeEvent() → reject(), the same route Esc takes. canon_window_test covers Esc → reject(), and the review's probe of the production dialog covered Esc, close, reject, accept, explicit done() and direct destruction.
• canon_window_test passes locally.
• The static-check scripts pass locally; the touchpoint manifest was regenerated.
• embed_screenshots.py --check and gen_reference.py --check pass.
• Not exercised: live radio. No test covers this window, and this PR adds none.

Separate from this PR: after a full sweep finishes, the slice is not left on the recommended value. On the demo, the window showed "knee 96" and AGC-T read 44. A build of main does the same ("knee 64", AGC-T 84). It lives in AgcTCalibrator, which this PR does not touch.

Checklist

• Commits are signed
• No new flat-key AppSettings calls. As a centered dialog it no longer saves its geometry.
• Code is clean-room
• All meter UI uses MeterSmoother (unchanged)
• Documentation updated: docs/user/docs/rx-controls.md, docs/style/*
• Security-sensitive changes: n/a

🤖 Generated with Claude Code

[ten9876]

Review of 58acb76e71e5f44140278e46c7405f89b69a3649: Approve with nits, subject to the remaining required CI checks. The PR addresses the AGC-T Calibration item explicitly picked in #6239 under approved RFC #6226: CanonWindow chrome and plot tokens, plus restoration when dismissing an active sweep. I reproduced the restoration defect on the merge base and its fix on the head. No unaddressed scope requirement or demonstrated correctness blocker found.

Scope audit

Files/group	Change	Claimed?	Verdict
src/gui/AgcCalibrationDialog.{cpp,h}	Canon chrome, controls and plot tokens; stop active sweep in done/destructor	Yes	In scope
src/gui/MainWindow.cpp	Lazy-create Canon dialog outside persistent frameless integration	Yes	In scope
Three docs/style/* files	Register the migrated window and theme scope	Yes	In scope
docs/user/docs/rx-controls.md	Closing shortcuts and sweep restoration	Yes	In scope
docs/architecture/aetherd-touchpoints.md	ThemeManager includers 172→173	Yes	In scope

All eight files are explained by the body and #6239. The single relevant commit has a verified good GPG signature. The removal of saved geometry and Frameless Window following is disclosed and authorized by the canon migration ruling. No unrelated hunks, new config/protocol surface, changed shared token defaults or baseline weakening found.

Blockers

None.

Non-blocking nits

1. Pin the derived dialog's restoration behavior in a durable regression test. src/gui/AgcCalibrationDialog.cpp:338–351: canon_window_test tests generic CanonWindow Escape/reject and Ctrl+W, but never constructs AgcCalibrationDialog or its calibrator. It cannot detect deletion of either new stop guard. A socket-free behavioral seam is available: an unattached SliceModel, null radio/audio dialog dependencies, an active sweep, then close/reject/Escape/direct destruction; assert the original threshold and no later timer-driven change. Also pin completed/applied recommendation preservation and slice removal.

   My temporary actual-production-dialog probe passed all six dismissal/destruction variants on the head and failed all six on the merge base. That and the before/after demo evidence demonstrate this fix; the nit is retaining the protection in the repository. No synthetic firmware peer is needed, and no per-PR CI allow-list expansion is requested.

2. Correct the PR body's Escape/background-sweep explanation. src/gui/MainWindow.cpp:4740 sets WA_DeleteOnClose, as the merge-base showOrRaisePersistent() already did. With that production attribute, Escape's QDialog::done path deletes the old dialog; its timer does not keep stepping behind a hidden window. On the merge base, an actual-dialog probe with the attribute set returned:

   productionDeleteOnClose escape alive=0 during=92 later=92
   

   Without DeleteOnClose, the hidden-dialog continuation does reproduce (92 immediately after Escape, 80 later, still running), but that is not the MainWindow-created dialog. The important production bug remains real: dismissal leaves AGC-T at the sweep's intermediate value. Please replace the body's main-window explanation with: “On main, dismissing the window during an Auto Sweep stopped the dialog's timer on deletion but left AGC-T at the intermediate sweep value. The new done() path restores the starting value before dismissal, and the destructor covers direct destruction while the slice still exists.”

What I tried to break

• Build/test: exact head and actual merge base e56cb0ca664db9b5c4c12a36d8810faa8e40c8fd built in the review-owned scratch checkout using lean RelWithDebInfo, Qt 6.12 and shared core. Only AetherSDR and the inspected socket-free canon_window_test were built; the latter passed. No added/modified tests and no socket-owning test target were found in preflight. No broad suite was run.

• Socket-free production-dialog attacks: temporary probe linked the actual application object graph with a custom main and invoked the actual dialog/model/timer methods. Close, reject, Escape, accept, direct destruction and explicit done all restored 65 from 92, remained 65 after 850 ms and stopped the sweep on the head. On the base, all six restoration assertions failed; non-deleting dismissal continued to 80, and destruction stayed at 92. Completed/applied recommendation 50 survived closing; deleting the slice during a sweep then destroying the dialog survived. This is local state-machine evidence, not a claim about firmware convergence.

• Before/after demo bridge: fresh isolated settings, offscreen, explicit sockets aethersdr-pr6372-base and aethersdr-pr6372-head, DEMO-0001 only, TX disabled. Both started at 65 and reached 60 mid-sweep. Base close AgcCalibrationDialog left the following response three seconds later:

  {"model":"slice","ok":true,"property":"agcThreshold","value":60}

  Head corner-close restored and retained:

  {"model":"slice","ok":true,"property":"agcThreshold","value":65}

  A separate head bridge close also restored 65. Reopening worked; idle, mid-sweep and completed captures showed the 460×460 canon header, uncut controls, cyan curve and gold knee marker. Apply set the completed recommendation to 12; closing retained 12. Both owned instances (head PID 3380557, base PID 3385834) exited. No live radio was selected or driven.

• Source/governance attacks: QPointer guards cover slice destruction; stop emits while dialog controls still exist; completed sweeps are deliberately excluded from rollback. Theme changes connect to plot update, and painted colors use scoped canon tokens. Raw radio/audio pointers are not accessed by the new destructor. Base/head engine findings are byte-identical (102), capability records remain 70, command-plane output remains 32 files/368 commands. Both touchpoint manifests are current; only the declared ThemeManager includer grows. Dialog accessibility checker finds zero on both sides. Generated reference check (8 pages) and screenshot embedding check (119 shots) pass. The stale rx-agc-calibration.png is explicitly disclosed for recapture, as project guidance permits.

No model-invocable automated code-review skill was available; this was a manual adversarial pass with independent governance and lifetime audits. Live firmware, native window-manager placement and theme switching were not exercised. Plot screenshots were captured offscreen; Escape was exercised in the production-dialog probe, while Ctrl+W was covered by the existing generic CanonWindow test plus the inspected shared reject/done dispatch.

CI freshness/status: main remained e56cb0ca664db9b5c4c12a36d8810faa8e40c8fd (2026-10-11 02:02:48 UTC). Pull-request CI/static/docs runs were created at 04:11:50 UTC and include that current main. At the final status read, six applicable checks passed, Linux/Windows/macOS builds were still running, and release-only PDF attachment was skipped. No completed check failed; this does not claim pending builds passed.

Recommendation: Approve with nits. The before/after behavior and lifecycle probes support the fix, and the visual changes follow the explicitly approved scope. Add durable close-path coverage and correct the body's Escape explanation; complete the required build checks and normal CODEOWNERS review before merge. This is a COMMENT review; formal approval remains the operator's call.

[aethersdr-agent]

Issue fit

Partially. #6239's picked list names this window with exactly this scope ("a dialog with the plot in color.canon.*; every close path stops a running sweep and restores AGC-T"), and the chrome/palette half lands cleanly: CanonWindow(Kind::Dialog), canon/agcCalibration container, header, applyCanonSheet on bodyWidget(), and AgcCurveWidget repainting from color.canon.* on themeChanged. The close-path half is real but incomplete: done() only acts while the sweep is running, and the post-sweep state — the one the operator hits most — is left on an unconfirmed value with no way back to the original. Detail in Blockers/Needs-decision below.

Scope

File / group	What it changes	Claimed?	Verdict
src/gui/AgcCalibrationDialog.{h,cpp}	PersistentDialog → CanonWindow, canon sheet + tokens in the plot, done()/dtor sweep stop	Yes	In scope
src/gui/MainWindow.cpp:4733-4746	direct construct + WA_DeleteOnClose instead of showOrRaisePersistent	Yes	In scope; matches the NetworkDiagnosticsDialog sibling at MainWindow.cpp:4700-4717 exactly
docs/style/{aethersdr-style-guide,dialog-patterns,theme-style-guide}.md	add AGC-T Calibration to the canon lists	Yes	In scope
docs/user/docs/rx-controls.md	close keys + what closing mid-sweep does	Yes	In scope, and accurately scoped to "during an Auto Sweep"
docs/architecture/aetherd-touchpoints.md	core/ThemeManager.h 172 → 173	Yes	In scope and required: python3 tools/gen_touchpoint_manifest.py --check exits 0 on the head checkout, so the hand count is right. Only core/+models/ headers are rows, so dropping gui/PersistentDialog.h needs no row

No unrelated files, no new public/protocol surface, no settings keys added, no CHANGELOG.md entry. Nothing in the diff is unexplained by the issue.

Two disclosed, non-hidden behavior changes, both stated in the body: geometry persistence is dropped (the old AgcCalibrationDialogGeometry key is now unused and the window centres on the parent), and the window no longer follows View → Frameless Window. Both are CanonWindow's documented defaults (docs/style/dialog-patterns.md:236-240), and Kind::Dialog for a short sweep tool is defensible — unlike AetherGPS (#6364), which kept its key via setGeometryKey().

Blockers

None — nothing here regresses main, and the only correctness gap below was equally broken before this PR.

Needs maintainer decision

1. src/gui/AgcCalibrationDialog.cpp:345-352 — "every close path … restores AGC-T" does not hold for the finished-sweep path, which is the common one.

   void AgcCalibrationDialog::done(int result)
   {
       if (m_engine.isRunning()) {
           m_engine.stop(); // restores the original value
       }
       CanonWindow::done(result);
   }

   AgcTCalibrator::finishSweep() (src/core/AgcTCalibrator.cpp:202-214) clears m_running/m_auto and emits finished(false) — deliberately not confirmed: its own comment says "They still confirm with Apply (keep) or Stop (restore original)." But onFinished() (src/gui/AgcCalibrationDialog.cpp:565-566) resets the button to "Auto Sweep", so Stop no longer exists after a sweep finishes — Apply or closing the window are the only exits, and closing now takes the isRunning() == false branch and does nothing.

   Your own test plan supplies the evidence that this is not merely "an applied recommendation is never reverted": "the window showed 'knee 96' and AGC-T read 44". 44 is a sweep intermediate (100 → 0 in steps of 4), not the recommendation and not the operator's original. So the sequence open → Auto Sweep → let it finish → close leaves the slice on a value that is neither what the operator had nor what the window recommended, and the original (your 65) is unrecoverable from the UI. The body's defence conflates the two states the engine keeps separate: finished(true) from applyRecommendation() versus finished(false) from finishSweep().

   This is a maintainer call, not a defect I can rule on: does closing an unconfirmed calibration mean keep or cancel? What I'd ask either way is that the title and body stop claiming a guarantee that has this hole. If the answer is cancel, the mechanical shape is a dialog-side flag — stop() when not running does still restore (m_originalValue >= 0 → applyValue), but calling it unconditionally would also revert a genuinely applied recommendation, since applyRecommendation() never clears m_originalValue:

   // In onFinished(bool applied):
   m_resultUnconfirmed = !applied && m_engine.hasRecommendation();
   
   // In onStarted(): m_resultUnconfirmed = false;
   
   void AgcCalibrationDialog::done(int result)
   {
       if (m_engine.isRunning() || m_resultUnconfirmed) {
           m_engine.stop(); // restores the original value
       }
       CanonWindow::done(result);
   }

   Separately: thank you for disclosing the knee-96/AGC-T-44 discrepancy as pre-existing in AgcTCalibrator — I confirmed finishSweep() does call applyValue(m_recommended), so something downstream is not sticking. That deserves its own issue rather than a paragraph in this PR body; no issue is linked for it.

Nits (non-blocking)

• src/gui/AgcCalibrationDialog.cpp:338-352 — no test covers the new close path. AgcCalibrationDialog.cpp is in no test target and links RadioModel + AudioEngine, and the nearest precedent (#6340's "every close path cancels an armed WSPR beacon") added none either — psk_reporter_map_behavior_test is a pure-core test. I'm not asking for a fake peer or a new GUI target; the honest statement is the one you already made ("No test covers this window, and this PR adds none"). If the restore semantics above get settled, the resulting rule is a socket-free seam worth pinning at the AgcTCalibrator level.
• #6239's "Picked" list — the item naming this PR was added to the tracking issue body at 04:11:54Z, eight seconds after this PR opened, by you rather than by a maintainer comment; the thread's only rulings are the #6226 approval and the #6273 one. Not a scope problem in practice — e56cb0ca6 (#6364) merged under exactly this pattern — but worth one line of maintainer confirmation.
• docs/user/docs/rx-controls.md:121 — the body notes rx-agc-calibration.png is now stale; please make sure the recapture issue exists so the screenshot doesn't sit wrong indefinitely.

What I tried to break

• Close-path plumbing. ✕ → QDialog::close (src/gui/CanonWindow.cpp:83) → closeEvent → reject(); Ctrl+W/⌘W → QDialog::reject via the QKeySequence::Close shortcut (:88); Escape → QDialog::reject. All three land in the done() override, and main's AgcCalibrationDialog has no closeEvent/hideEvent/reject() of its own (only the m_engine.stop() inside onStartStop), so the PR's description of the pre-existing Esc behavior checks out.
• Use-after-free in the override. m_engine.stop() runs before CanonWindow::done(result), which is the ordering that matters: with WA_DeleteOnClose the base call can destroy this, and nothing after it touches a member. Reversed, this would be a real UAF.
• Double restore / dtor reentrancy. ~AgcCalibrationDialog re-guards on isRunning(), so the close path cannot restore twice. stop() emitting finished(false) from inside the derived destructor body reaches onFinished(), which writes m_startStopBtn/m_recLabel/m_curve — those children are still alive there (~QWidget deletes them later), so it is safe, if subtle.
• Reentrancy of the restore write. stop() → applyValue() → agcThresholdChanged → onValueChanged (m_auto is false, so the manual timer arms) and refreshFromSlice(). Harmless on a hiding window; on the ✕ path the timer dies with the dialog. m_slice is a QPointer and every engine call site null-checks, so a slice removed mid-sweep does not dangle through the restore.
• Manual mode. onValueChanged never sets m_running, so closing the window after hand-moving the AGC-T slider does not revert the operator's own setting — the restore is correctly confined to sweeps.
• Theme tokens and scope. All twelve tokens used by kAgcCalibrationStyle and the plot (inkSoft, ink, cyan, aqua, muted, control, nested, line, lineHi, grid, onAccent, sparkGold) exist under scopes/root/tokens/color/canon in both default-dark.json and default-light.json. canon/agcCalibration is absent from the theme JSON, but so is every sibling (canon/aetherGps, canon/aetherRx, …): theme::setContainer → registerDeclaredContainer → scopeOrCreate builds it at runtime and lookupRaw's parent walk falls back to canon then root. House pattern, not a gap. Dropping WA_StyledBackground on AgcCurveWidget is consistent with it now painting its own card.
• Manifest and CI. gen_touchpoint_manifest.py --check → "manifest up to date". All 10 checks on 58acb76 are success/skipped, including check-windows (the -DENABLE_ASR=OFF lane) and Static checks.
• CodeGuard. All 28 findings on MainWindow.cpp refuted — credit to security-audit (CodeGuard): none falls in this PR's changed range (4733-4746), the CMDI-AMP/CMDI-BACKTICK hits are C++ & and Markdown backticks in // comments, PATH-PROC is /proc/self/status and the app's own bundle path, CS-PII-IP is the WSJT-X multicast default 224.0.0.1, and role_override is the word "override" in a QRM-classifier comment. Nothing to carry forward.
• Could not check: anything runtime. I have no build, no test run and no way to drive the GUI, so every finding above is reasoned from the code at 58acb76, not reproduced. In particular I could not reproduce your knee-96/AGC-T-44 observation, and I could not verify the visual result of the canon sheet.

Recommendation

Needs maintainer decision, then approve. The chrome, palette and call-site conversion are clean and match the merged AetherGPS/Network Diagnostics precedent down to the WA_DeleteOnClose + QPointer shape, the manifest is honest, and the mid-sweep restore is a genuine improvement over main. The one open question is whether closing an unconfirmed finished sweep should also restore — your own evidence shows that path leaves the slice on a sweep intermediate, so the title's "every close path" currently overstates what done() does. Next step: get the maintainer's call on keep-vs-cancel, adjust done() (or just the title and body) accordingly, and file the AgcTCalibrator knee/value discrepancy as its own issue. Nice work on the close-path diagnosis and on disclosing the pre-existing bug rather than folding it in.

---

_{🤖 aethersdr-agent · cost: $9.3699 · model: claude-opus-5}

[aethersdr-agent]

Cisco CodeGuard — static analysis of this PR (33 finding(s))

• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:9693
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:9805
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:9927
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:9928
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:9929
• [HIGH] CS-VLN-PATH-PROC — Vulnerability: CS-VLN-PATH-PROC in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:6224
• [HIGH] CS-VLN-PATH-PROC — Vulnerability: CS-VLN-PATH-PROC in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:6303
• [CRITICAL] CS-VLN-CMDI-AMP — Vulnerability: CS-VLN-CMDI-AMP in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:526
• [CRITICAL] CS-VLN-CMDI-AMP — Vulnerability: CS-VLN-CMDI-AMP in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:556
• [CRITICAL] CS-VLN-CMDI-AMP — Vulnerability: CS-VLN-CMDI-AMP in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:559
• [CRITICAL] CS-VLN-CMDI-AMP — Vulnerability: CS-VLN-CMDI-AMP in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:581
• [CRITICAL] CS-VLN-CMDI-AMP — Vulnerability: CS-VLN-CMDI-AMP in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:3660
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:1280
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:1804
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:1896
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:1973
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:2015
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:2050
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:2345
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:3602
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:3693
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:6166
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:7972
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:8037
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:8111
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:8196
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:8377
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:8580
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:9794
• [LOW] CS-PII-IP — PII detected: ip_address in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:6916
• [CRITICAL] CS-INJ-role_override — Prompt injection: role override attempt in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:11745
• [CRITICAL] CS-INJ-role_override — Prompt injection: role override attempt (detected after NFKC normalization) in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:11745
• [HIGH] CS-INJ-homoglyph — Mixed Unicode scripts detected (possible homoglyph attack) in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-6372/src/gui/MainWindow.cpp:0

_{Automated static scan by Cisco DefenseClaw CodeGuard on the changed files. Advisory — some may be false positives; the review above verifies them.}

---

_{🤖 aethersdr-agent · cost: $9.4944 · model: claude-opus-5}