packet-tracer-skill 0.2.0 → 0.2.2

package/docs/github-launch-ops-0.2.2.md

@@ -0,0 +1,42 @@
+# GitHub Launch Ops for `v0.2.2`
+
+## Current Status
+
+- npm package target is `packet-tracer-skill@0.2.2`
+- release body source is ready: `docs/release-notes-0.2.2.md`
+- launch wording source is ready: `docs/launch-announcement-0.2.2.md`
+- About text and Topics source remain: `docs/github-metadata.md`
+- hero visual remains fixed: `examples/screenshots/complex_campus_master_edit_v4.png`
+
+## Exact GitHub Release Steps
+
+1. Ensure tag `v0.2.2` exists and points to the publish commit.
+2. Open GitHub Releases for `20hajiyev/packet-tracer-skill`.
+3. Create a new release from tag `v0.2.2`.
+4. Use title `v0.2.2`.
+5. Paste the body from `docs/release-notes-0.2.2.md`.
+6. Do not upload raw `.pkt` binaries or local bridge artifacts.
+7. Keep the first visual aligned with `examples/screenshots/complex_campus_master_edit_v4.png`.
+
+## About and Topics
+
+Apply the exact text from `docs/github-metadata.md`.
+
+Do not rewrite these ad hoc in the UI. The doc is the source of truth.
+
+## Discussions
+
+If Discussions are not already enabled, enable them and create these categories:
+
+- `Showcase`
+- `Q&A`
+- `Donor Requests`
+- `Capability Roadmap`
+
+## Launch Message Sources
+
+Use:
+
+- `docs/release-notes-0.2.2.md` for the release body
+- `docs/launch-announcement-0.2.2.md` for the npm/GitHub/social wording
+- `docs/hero-demo-plan.md` for the screenshot caption and demo claim guardrails

package/docs/github-metadata.md

@@ -21,13 +21,30 @@ Donor-backed Cisco Packet Tracer 9.x skill for natural-language planning, safe-o
 
 Use the complex campus Packet Tracer screenshot as the first public visual until a dedicated hero demo GIF is ready.
 
-Pinned screenshot:
-
-- `examples/screenshots/complex_campus_master_edit_v4.png`
+Pinned screenshot:
+
+- `examples/screenshots/complex_campus_master_edit_v4.png`
+
+Pinned caption:
+
+- `donor-backed complex campus proof artifact for the 0.2.2 public preview`
+
+## Release Source
+
+- release title: `v0.2.2`
+- release body source: `docs/release-notes-0.2.2.md`
+- launch wording source: `docs/launch-announcement-0.2.2.md`
+
+## Discussions Categories
+
+- `Showcase`
+- `Q&A`
+- `Donor Requests`
+- `Capability Roadmap`
 
 ## Public Message Guardrails
 
 - say `donor-backed`, `open-first`, `scenario-aware`, and `Windows-first runtime`
-- say `validated with external bridge override` when referring to strict runtime validation
-- do not say the repo is self-contained runtime-ready unless doctor semantics change
-- keep README, release notes, and GitHub About text aligned with the same wording
+- say `validated with external bridge override` when referring to strict runtime validation
+- do not say the repo is self-contained runtime-ready unless doctor semantics change
+- keep README, release notes, and GitHub About text aligned with the same wording

package/docs/hero-demo-plan.md

@@ -2,7 +2,7 @@
 
 ## Goal
 
-Prepare one conservative hero demo flow for the `0.2.0` public preview surface without implying self-contained runtime readiness.
+Prepare one conservative hero demo flow for the `0.2.1` public preview surface without implying self-contained runtime readiness.
 
 ## Prompt
 
@@ -22,10 +22,12 @@ python .\scripts\generate_pkt.py --parity-report "6 department campus with route
 python .\scripts\runtime_doctor.py
 ```
 
-## Visual
-
-- pinned image: `examples/screenshots/complex_campus_master_edit_v4.png`
-- reuse the complex campus topology screenshot as the hero visual until a dedicated GIF is produced
+## Visual
+
+- pinned image: `examples/screenshots/complex_campus_master_edit_v4.png`
+- reuse the complex campus topology screenshot as the hero visual until a dedicated GIF is produced
+- alt text: `Donor-backed complex campus Packet Tracer topology with VLAN, management, ACL, and wireless edits`
+- visual label: `Complex Campus hero visual`
 
 ## Claims To Make
 
@@ -35,8 +37,14 @@ python .\scripts\runtime_doctor.py
 - Windows-first runtime
 - validated with external bridge override
 
-## Claims Not To Make
-
-- do not say the repo is self-contained runtime-ready
-- do not claim full synthetic generate for WAN/security coverage
-- do not imply unsupported or acceptance-gated mutations are generated anyway
+## Claims Not To Make
+
+- do not say the repo is self-contained runtime-ready
+- do not claim full synthetic generate for WAN/security coverage
+- do not imply unsupported or acceptance-gated mutations are generated anyway
+
+## Launch Caption
+
+Use this short caption when pairing the hero image with release notes or announcement text:
+
+`Donor-backed, open-first, scenario-aware Packet Tracer workflow with conservative Windows-first runtime truth.`

package/docs/home-iot-donor-proof.md

@@ -0,0 +1,64 @@
+# Home IoT Donor Proof
+
+## Proof Goal
+
+Show one honest public proof artifact for the canonical `home_iot` family without claiming broad synthetic smart-home generation.
+
+## Real Donor-Backed Artifacts
+
+- registry entry: `home_iot_cli_edit_v1.pkt`
+- proof sources:
+  - local inventory from the ignored donor-backed showcase lab
+  - checked-in edit roundtrip tests for `iot_registration_server.pkt`, `iot_home_gateway.pkt`, and wireless association donors
+- runtime mode used for the proof: Windows Packet Tracer 9.0 with an external bridge override
+
+## Inventory and Edit Proof
+
+Observed Home IoT proof facts:
+
+- a Home Gateway donor path exists
+- IoT thing inventory is visible
+- gateway-backed registration state is visible in inventory
+- edit roundtrip preserves:
+  - IoT registration to Home Gateway
+  - IoT registration to registration server
+  - IoT rule enable/disable state
+  - donor-backed wireless association
+
+## Donor-Backed Generate Interpretation
+
+The current product contract for Home IoT is intentionally narrow:
+
+- `iot_registration`, `iot_control`, and `wireless_client_association` are only considered generate-ready when a selected donor exists
+- the selected donor must match `IoT/home gateway` or a compatible `wireless-heavy` shape
+- the prompt must name deterministic targets such as the thing, gateway/server, client, AP/router, and SSID
+
+This is why the public wording uses `donor-backed constrained-generate` rather than broad `smart home generate-ready`.
+
+## What This Proves
+
+- Home IoT inventory proof exists
+- edit roundtrip proof exists for registration, control, and wireless association
+- donor-backed Home IoT readiness can be raised without guessed output
+- the intended blocker split remains explicit: donor selection vs acceptance vs runtime
+
+## What This Does Not Prove
+
+- it does not prove free-form smart-home topology generation is solved
+- it does not prove every prompt mentioning IoT registration is generate-ready
+- it does not remove the need for a selected donor and deterministic target resolution
+- it does not promote WAN/security features ahead of the next wave
+
+## Public Message Guardrail
+
+Say:
+
+- donor-backed Home IoT proof exists
+- registration/control and wireless association are integrated only inside a constrained donor-backed path
+- explicit target naming still matters
+
+Do not say:
+
+- all IoT support is solved
+- any smart-home prompt can now generate a correct `.pkt`
+- donor-backed proof makes runtime or selector constraints disappear

package/docs/launch-announcement-0.2.1.md

@@ -0,0 +1,15 @@
+# `0.2.1` Launch Announcement Draft
+
+## npm Publish Announcement
+
+`packet-tracer-skill 0.2.1` is live on npm.
+
+Donor-backed Cisco Packet Tracer 9.x skill for natural-language planning, open-first `.pkt` workflows, scenario-aware reporting, parity checks, and Windows-first runtime diagnostics.
+
+## GitHub Release Intro
+
+`0.2.1` is a conservative public preview patch release. It keeps the current donor-backed workflow, the scenario-aware decision layer, the runtime doctor contract, and the known working scenario set intact while tightening the published package surface.
+
+## Short Social Summary
+
+Published `packet-tracer-skill@0.2.1`: donor-backed, open-first, scenario-aware Packet Tracer workflow with parity reporting, runtime doctor output, and a known working scenario set. Windows-first runtime, validated with external bridge override.

package/docs/launch-announcement-0.2.2.md

@@ -0,0 +1,15 @@
+# `0.2.2` Launch Announcement Draft
+
+## npm Publish Announcement
+
+`packet-tracer-skill 0.2.2` is live on npm.
+
+This patch tightens runtime setup documentation and adds an advanced wireless feature wave: WEP and WPA Enterprise/RADIUS are edit-proven for explicit deterministic targets, while WLC, Meraki, cellular, Bluetooth, beamforming, and guest Wi-Fi remain report-only.
+
+## GitHub Release Intro
+
+`0.2.2` is a conservative public preview patch release. It keeps the donor-backed, open-first Packet Tracer workflow intact while improving runtime setup clarity and aligning advanced wireless parser, atlas, parity, and proof docs.
+
+## Short Social Summary
+
+Published `packet-tracer-skill@0.2.2`: README runtime cleanup, generic Twofish bridge guidance, and advanced wireless atlas/edit-proof support for WEP and WPA Enterprise/RADIUS. Windows-first runtime, validated with external bridge override.

package/docs/packet-tracer-feature-gap-atlas.md

@@ -0,0 +1,87 @@
+# Packet Tracer Feature Gap Atlas
+
+This atlas is the public truth source for Packet Tracer 9.0 features that exist in local Cisco samples but are not yet fully productized by this skill.
+
+It is intentionally conservative:
+
+- `inventory_known` means a Packet Tracer sample or path proves the feature exists.
+- `report_supported` means the skill can recognize and report the feature without claiming mutation support.
+- `edit_proven` requires a roundtrip editor test.
+- `donor_backed_ready` requires selected-donor evidence.
+- `generate_ready` requires acceptance-backed generate behavior.
+
+The atlas does not claim that every Packet Tracer feature is generate-ready. It turns missing or under-modelled Packet Tracer features into an auditable backlog before any broad config mutation is opened.
+
+## First Generate Enablement Wave
+
+The first promotion wave is `ipv6_routing`. The following subset can move beyond report-only only when explicit router/interface targets and an IPv6/routing donor are selected:
+
+- IPv6 interface/SLAAC config
+- DHCPv6 stateful pool binding
+- OSPFv3 interface routing
+- EIGRP IPv6 interface routing
+- RIPng interface routing
+- IPv6 HSRP virtual address
+
+IPv6 tunneling, ISATAP, prefix delegation, and AAAA DNS remain report-first until separate donor-backed editor proof exists.
+
+## Second Edit-Proven Wave
+
+The second promotion wave is `l2_security_monitoring`. The following subset is edit-proven for explicit commands, but still not broad generate-ready:
+
+- DHCP snooping
+- Dynamic ARP Inspection
+- LLDP
+- REP
+- SNMP community
+- NetFlow export
+- SPAN/RSPAN
+- Port security
+
+802.1X/NAC and QoS remain report-first in this wave. Decode-fail Packet Tracer samples can prove that a feature exists by path/catalog evidence, but they do not create edit or generate readiness by themselves.
+
+## Third Edit-Proven Wave
+
+The third promotion wave is `wireless_advanced`. This wave deliberately promotes
+only the safest explicit wireless edit subset:
+
+- WEP SSID/security mutation
+- WPA Enterprise/RADIUS SSID/security intent
+
+These capabilities can report `edit_supported=true` only when the prompt is an
+explicit wireless edit command with a deterministic AP/router/WLC target and
+SSID. They still report `generate_supported=false` and
+`generate_mismatch_reason=supported_in_edit_only`.
+
+WLC/controller workflows, Meraki, cellular/5G, Bluetooth, beamforming, and
+guest Wi-Fi remain report-only until separate donor-backed editor proof exists.
+
+## Current Feature Families
+
+- `ipv6_routing`: SLAAC, DHCPv6, prefix delegation, AAAA DNS, IPv6 tunneling, ISATAP, OSPFv3, EIGRP IPv6, RIPng, HSRP.
+- `l2_security_monitoring`: DHCP snooping, DAI, 802.1X/NAC, LLDP, REP, SNMP, NetFlow, SPAN/RSPAN, QoS, port security.
+- `wan_security_edge`: ASA ACL/NAT, ASA service policy, clientless VPN, CBAC, ZFW, sniffer, IPSec variants.
+- `wireless_advanced`: WLC, WPA Enterprise/RADIUS, WEP/WPA modes, guest Wi-Fi, beamforming, Meraki, 5G/cellular, Bluetooth.
+- `automation_controller`: Network Controller, Python, JavaScript, Blockly, TCP/UDP test apps, VM/IOx samples.
+- `voice_collaboration`: VoIP, IP phones, Call Manager-style telephony, Linksys voice.
+- `industrial_iot`: MQTT, Real HTTP, Real WebSocket, visual scripting, PTP, Profinet, L2NAT, CyberObserver, industrial firewall.
+- `physical_media_device`: coaxial, cable/DSL, central office, cell tower, power distribution, hot-swappable modules, IOS/license workflows.
+
+## CLI
+
+```powershell
+python .\scripts\generate_pkt.py --feature-gap-report
+```
+
+The report includes:
+
+- total Packet Tracer feature groups tracked
+- mapped and unmapped feature counts
+- status counts by support level
+- sample-backed feature counts
+- top missing feature families
+- per-feature evidence from parser, catalog, coverage, editor tests, and Packet Tracer sample paths
+
+## Product Rule
+
+Feature atlas support is not the same as generation support. A feature can be visible in `--feature-gap-report` and still remain blocked in `--explain-plan`, `--compare-scenarios`, or `--parity-report` until donor-backed proof exists.

package/docs/post-launch-follow-up.md

@@ -0,0 +1,39 @@
+# Post-Launch Follow-Up
+
+## Immediate Follow-Up Items
+
+- complete GitHub launch ops from `docs/github-launch-ops-0.2.2.md`
+- publish one canonical donor proof artifact: `docs/campus-donor-proof.md`
+- publish one Home IoT donor proof artifact: `docs/home-iot-donor-proof.md`
+- publish one WAN/security donor proof artifact: `docs/wan-security-donor-proof.md`
+- keep README, release notes, launch announcement, and GitHub metadata in sync
+
+## Next Technical Proof Batch
+
+- use the canonical `campus` donor proof path first
+- close shorthand campus family fidelity before broadening scenario scope
+- improve selected donor reasoning visibility before adding new capability scope
+- preserve the difference between donor-limited refusal and runtime-blocked refusal
+- make the closest rejected donor class and primary rejection code visible in the public decision surface
+- lift Home IoT only through donor-backed deterministic targets, not broad smart-home synthesis
+
+## Runtime Clarity Improvements
+
+- keep `validated with external bridge override` wording consistent
+- make `validate_open ready but strict generate blocked` easier to read in both docs and doctor output
+- treat runtime clarity as a product surface, not a debug detail
+- keep `what_currently_works`, `what_is_blocked`, and `best_next_fix` aligned with `doctor_summary`
+
+## Trigger Conditions for `0.2.2` or the Next Minor
+
+- README / npm / GitHub wording drift
+- donor proof uncovers a concrete selector mismatch worth productizing
+- runtime doctor wording becomes ambiguous again
+- examples and public proof artifacts stop matching current behavior
+- selected donor refusal becomes too generic to explain the closest rejected donor class
+
+## Next Integration Wave
+
+- after the Home IoT and wireless internal gate closes, keep `wan_security_edge` scoped to report/selection plus donor-backed readiness
+- next constrained edit candidates remain `vpn`, `ipsec`, `gre`, `ppp`, `security_edge`, and `multilayer_switching`
+- do not open that wave until the Home IoT proof and readiness wording are stable

package/docs/publish-preview-roadmap.md

@@ -9,23 +9,26 @@
 - docs and runtime wording match actual behavior
 - template fallback assets are checked in and release-surface tests protect them
 
-## Step B: Public `0.2.x` Publish-Preview
-
-- `package.json` is versioned at `0.2.0`
-- release notes draft is ready: `docs/release-notes-0.2.0.md`
-- hero visual is locked to `examples/screenshots/complex_campus_master_edit_v4.png`
-- hero demo execution plan is ready: `docs/hero-demo-plan.md`
-- GitHub About/Topics text is finalized in `docs/github-metadata.md`
-- npm publish checklist is complete and conservative runtime wording is preserved
-- final publish batch should only do:
-  - npm publish
-  - GitHub release creation
-  - About/Topics update in GitHub UI
-  - Discussions opening and release announcement
+## Step B: Public `0.2.x` Publish-Preview
+
+- `package.json` is versioned at `0.2.2`
+- npm publish target is `packet-tracer-skill@0.2.2`
+- release notes source is ready: `docs/release-notes-0.2.2.md`
+- hero visual is locked to `examples/screenshots/complex_campus_master_edit_v4.png`
+- hero demo execution plan is ready: `docs/hero-demo-plan.md`
+- GitHub About/Topics text is finalized in `docs/github-metadata.md`
+- launch ops runbook is ready: `docs/github-launch-ops-0.2.2.md`
+- npm publish checklist is complete and conservative runtime wording is preserved
+- remaining public launch ops are:
+  - GitHub release creation
+  - About/Topics update in GitHub UI
+  - Discussions opening
+  - release announcement application
 
 ## Step C: `1.0.0` Preparation
 
-- at least one populated curated donor path is actively used in practice
-- runtime messaging remains conservative and stable
-- one richer example family or improved `wan_security_edge` reporting is added
-- publish-preview feedback is folded back into docs and trust surface
+- at least one populated curated donor path is publicly proven in practice
+- runtime messaging remains conservative and stable
+- one richer example family or improved `wan_security_edge` reporting/proof is added
+- publish-preview feedback is folded back into docs and trust surface
+- post-launch follow-up is tracked in `docs/post-launch-follow-up.md`

package/docs/release-checklist.md

@@ -1,6 +1,6 @@
 # Release Checklist
 
-Target release surface: `0.2.0` conservative public preview prep.
+Target release surface: `0.2.2` conservative public preview.
 
 ## Product Contract
 
@@ -32,20 +32,24 @@ python .\scripts\runtime_doctor.py
 - raw `.pkt` binaries are not committed
 - examples index and gallery were rebuilt
 - screenshots are intentional and non-sensitive
-- changelog entry is updated for `0.2.0`
-- release notes draft exists: `docs/release-notes-0.2.0.md`
-- hero demo plan exists: `docs/hero-demo-plan.md`
-- hero visual is selected: `examples/screenshots/complex_campus_master_edit_v4.png`
-- runtime truth docs match current `runtime_grade` and `bridge_resolution` semantics
-- curated donor registry entries are reviewed for promotion status and provenance
+- changelog entry is updated for `0.2.2`
+- release notes source exists: `docs/release-notes-0.2.2.md`
+- hero demo plan exists: `docs/hero-demo-plan.md`
+- GitHub launch ops runbook exists: `docs/github-launch-ops-0.2.2.md`
+- canonical donor proof exists: `docs/campus-donor-proof.md`
+- hero visual is selected: `examples/screenshots/complex_campus_master_edit_v4.png`
+- runtime truth docs match current `runtime_grade` and `bridge_resolution` semantics
+- curated donor registry entries are reviewed for promotion status and provenance
 
 ## GitHub Surface
 
 - CI workflow is green
 - issue templates are present
 - contributing and security docs exist
-- citation metadata exists
-- About/Topics are ready to be updated in GitHub UI
+- citation metadata exists
+- About/Topics are ready to be updated in GitHub UI
+- release body source is ready for direct paste into GitHub Releases
+- Discussions categories are decision-complete in docs
 
 ## Publish Gate
 
@@ -55,6 +59,12 @@ Only publish when:
 - README renders cleanly
 - `package.json` version is final for the publish-preview batch
 - doctor wording matches current runtime reality
-- no accidental local paths leaked into tracked files
-- GitHub metadata doc is final and matches README wording
-- hero visual and release notes are ready for direct reuse
+- no accidental local paths leaked into tracked files
+- GitHub metadata doc is final and matches README wording
+- hero visual and release notes are ready for direct reuse
+
+## Post-Publish Follow-Up
+
+- apply GitHub launch ops if they were not automated
+- publish one canonical donor proof note
+- use `docs/post-launch-follow-up.md` as the source for the next patch trigger conditions

package/docs/{release-notes-0.2.0.md → release-notes-0.2.1.md}

@@ -1,8 +1,8 @@
-# `packet-tracer-skill` `0.2.0` Release Notes Draft
+# `packet-tracer-skill` `0.2.1` Release Notes Source
 
 ## Summary
 
-`0.2.0` is a conservative public preview prep release for `packet-tracer-skill`. It stabilizes the public release surface around donor-backed planning, open-first generation rules, scenario-aware reporting, and Windows-first runtime truth.
+`0.2.1` is a conservative public preview patch release for `packet-tracer-skill`. The npm package is already live, and this file is the source text for the GitHub release body.
 
 ## Highlights
 
@@ -14,12 +14,13 @@
 
 ## Runtime Notes
 
-- real `.pkt` runtime remains Windows-first
+- real `.pkt` runtime remains Windows-first runtime
 - strict validation is currently performed with an external bridge override when repo-local bridge assets are not bundled
 - public docs intentionally preserve the distinction between repo-local readiness and external bridge fallback
 
 ## Public Preview Intent
 
-- this release prepares the repo for npm publish and GitHub release
-- it does not change the product contract to imply `1.0.0` stability
-- publish should happen only after the short follow-up batch that applies the prepared metadata and release steps
+- `packet-tracer-skill@0.2.1` is already published on npm
+- GitHub release, About/Topics application, and Discussions setup still follow the prepared manual launch ops flow
+- it does not change the product contract to imply `1.0.0` stability
+- the next public-facing technical step is a canonical campus donor proof artifact, not broader synthetic scope

package/docs/release-notes-0.2.2.md

@@ -0,0 +1,26 @@
+# `packet-tracer-skill` `0.2.2` Release Notes Source
+
+## Summary
+
+`0.2.2` is a conservative patch release for the public preview line. It publishes the README runtime cleanup and the advanced wireless feature wave without changing the core safety posture.
+
+## Highlights
+
+- README runtime instructions now use generic Twofish bridge examples instead of a user-specific `.codex` path as the default
+- `PKT_TWOFISH_LIBRARY` and `PKT_TWOFISH_SEARCH_ROOTS` setup paths are documented separately
+- advanced wireless prompts classify into the `wireless_advanced` family
+- WEP and WPA Enterprise/RADIUS are represented as edit-proven only for explicit deterministic edit targets
+- WLC, Meraki, cellular, Bluetooth, beamforming, and guest Wi-Fi remain report-only unless future donor-backed edit proof is added
+- feature atlas and release-surface tests protect the conservative support claims
+
+## Runtime Notes
+
+- real `.pkt` runtime remains Windows-first runtime
+- strict validation is currently performed with an external bridge override when repo-local bridge assets are not bundled
+- public docs intentionally preserve the distinction between repo-local readiness and external bridge fallback
+
+## Public Preview Intent
+
+- `packet-tracer-skill@0.2.2` is the patch release for README cleanup and advanced wireless report/edit truth
+- this release does not claim `generate_ready` support for broad advanced wireless controller, cellular, Bluetooth, or Meraki scenarios
+- unsupported and acceptance-gated mutations still refuse instead of guessing

package/docs/runtime-truth.md

@@ -18,6 +18,35 @@ That distinction is part of the public product contract.
 - `blocked`
   Required donor, bridge, or Packet Tracer runtime pieces are missing.
 
+## How To Read `--doctor`
+
+- if `runtime_grade=ready`, strict decode/edit/generate and `validate_open` are available from the current checkout
+- if `runtime_grade=partially_ready`, at least one operation still works, but the product contract is not fully satisfied
+- if `runtime_grade=blocked`, no critical runtime path is ready enough to claim strict `.pkt` support
+
+High-signal fields:
+
+- `what_currently_works`
+  Short sentence for the operations that are usable right now.
+- `what_is_blocked`
+  Short sentence for the operations that are still blocked.
+- `why_it_is_blocked`
+  Product-facing reason for the current blocker set.
+- `best_next_fix`
+  The single next fix that should be done first.
+
+High-signal mixed case:
+
+- `validate_open` can be `ready` while `inventory`, `decode`, `edit`, and `generate` are blocked
+- this means Packet Tracer is installed, but the donor and/or bridge path is still not sufficient for strict `.pkt` work
+- in that state, `best_next_fix` should point at donor or bridge remediation before anything else
+
+Another mixed case:
+
+- all listed operations can be operationally ready while `bridge_resolution=external_env`
+- that still means the checkout is only partially ready as a packaged repo surface
+- docs should continue saying `validated with external bridge override` rather than implying repo-local readiness
+
 ## Bridge Resolution
 
 - `repo_local`
@@ -47,3 +76,5 @@ If tests pass only with an external bridge:
 - do not say "runtime ready" without qualification
 - do say "validated with external bridge override"
 - do preserve the difference between repo-local readiness and external fallback
+- do say when `validate_open` is ready but strict decode/edit/generate are still blocked
+- do keep `what_currently_works`, `what_is_blocked`, and `best_next_fix` aligned with `doctor_summary`

package/docs/wan-security-donor-proof.md

@@ -0,0 +1,41 @@
+# WAN/Security Edge Donor Proof
+
+## Proof Goal
+This proof records the current `wan_security_edge` truth after the Home IoT internal gate. It is a report/selection and donor-backed readiness proof, not a broad synthetic WAN/security generator claim.
+
+## Current Inventory And Report Proof
+- The fixture prompt `wan security edge, multilayer switch, cloud, firewall/ASA, GRE, PPP, site-to-site VPN, IPsec, ACL, NAT` maps to `wan_security_edge`.
+- The planner recognizes `vpn`, `ipsec`, `gre`, `ppp`, `multilayer_switching`, and `security_edge` as the expected capability family.
+- Static Packet Tracer samples with VPN/IPSec/GRE/PPP, ASA/security, WAN/cloud, and multilayer switch evidence are treated as `WAN/security edge` donors.
+- Capability parity remains conservative when no selected donor is available: the planner reports donor-limited readiness instead of guessing a final `.pkt`.
+
+## Donor-Backed Readiness Interpretation
+WAN/security readiness can only rise when a selected donor is already aligned with `WAN/security edge` and contains the requested capability evidence plus the required runtime feature:
+
+- `vpn`, `ipsec`, `gre`: tunnel-capable donor evidence
+- `ppp`: WAN/PPP donor evidence
+- `security_edge`: ASA/security donor evidence
+- `multilayer_switching`: multilayer switch donor evidence
+
+The prompt must explicitly request WAN/security intent, such as VPN, IPsec, GRE, PPP, ASA/firewall, cloud, multilayer, or site-to-site wording.
+
+## What This Proves
+- WAN/security prompts are family-correct and do not drift into `service_heavy`.
+- Packet Tracer sample inventory can identify WAN/security donor candidates.
+- Selected-donor readiness can be represented without changing the public JSON contract.
+- Refusal and remediation now point toward reusable ASA/cloud/serial/tunnel donor skeletons.
+
+## What This Does Not Prove
+- It does not claim full synthetic VPN/IPSec/GRE/PPP configuration generation.
+- It does not claim that every ASA/firewall or multilayer switch feature is editable.
+- It does not allow `reference_only` donors as final apply donors.
+- It does not change the `single-donor` final `.pkt` apply rule.
+
+## Next Constrained Edit Candidates
+- GRE tunnel parameter mutation on an existing routed donor.
+- PPP/CHAP/PAP mutation on an existing serial or PPPoE donor.
+- IPSec profile/key mutation on an existing site-to-site donor.
+- ASA ACL/NAT mutation on an existing security-edge donor.
+- SVI/routed-port mutation on an existing multilayer switch donor.
+
+These candidates need separate roundtrip proof before they become release claims.

package/docs/wireless-advanced-proof.md

@@ -0,0 +1,60 @@
+# Advanced Wireless Proof
+
+This proof records the current Packet Tracer 9.0 advanced wireless boundary.
+It is intentionally narrower than a generic WLC or enterprise Wi-Fi generation
+claim.
+
+## Current Proof
+
+The feature atlas recognizes advanced wireless sample families and prompt
+signals for:
+
+- `wlc`
+- `wpa_enterprise`
+- `wep`
+- `guest_wifi`
+- `beamforming`
+- `meraki`
+- `cellular_5g`
+- `bluetooth`
+
+The edit-proven subset is limited to explicit wireless SSID/security mutation
+where the target device and SSID are deterministic:
+
+```powershell
+python .\scripts\generate_pkt.py --parity-report "set AP1 ssid LEGACY security wep passphrase abc12345 channel 6"
+python .\scripts\generate_pkt.py --parity-report "set WLC1 ssid CORP security wpa-enterprise radius 192.168.1.10 secret radius123 channel 11"
+```
+
+Expected product interpretation:
+
+- `wep` can report `edit_supported=true`.
+- `wpa_enterprise` can report `edit_supported=true`.
+- Both remain `generate_supported=false`.
+- The deterministic mismatch reason is `supported_in_edit_only`.
+
+## What This Proves
+
+- The parser can classify advanced wireless prompts without drifting into
+  `service_heavy`.
+- WEP and WPA Enterprise/RADIUS can be represented as explicit edit intent.
+- The atlas can promote a narrow advanced-wireless subset to `edit_proven`.
+- WLC, Meraki, cellular, Bluetooth, beamforming, and guest Wi-Fi stay visible
+  as report-level Packet Tracer features.
+
+## What This Does Not Prove
+
+- It does not prove broad WLC/controller configuration generation.
+- It does not prove cellular, Bluetooth, Meraki, beamforming, or guest Wi-Fi edit
+  mutations.
+- It does not prove full WPA Enterprise AAA/RADIUS topology construction.
+- It does not make any advanced wireless feature `generate_ready`.
+
+## Next Safe Actions
+
+- Add donor-backed inventory proof for WLC and Meraki samples before any edit
+  promotion.
+- Keep cellular and Bluetooth in report mode until target resolution and device
+  runtime behavior are deterministic.
+- Promote only one feature at a time from report-only to edit-proven, then to
+  donor-backed readiness after acceptance evidence exists.