packet-tracer-skill 0.2.1 → 0.2.3

package/docs/automation-controller-proof.md

@@ -0,0 +1,35 @@
+# Automation Controller Proof
+
+This proof covers the narrow automation/controller wave for Packet Tracer programming surfaces. It is explicit script-file edit proof, not Network Controller GUI synthesis or broad automation topology generation.
+
+## What This Proves
+
+- Inventory can report existing Python, JavaScript, Blockly, and TCP/UDP app files without dumping full source code.
+- Existing Python and JavaScript script files can be replaced when the prompt quotes the device name, app name, and file name.
+- TCP/UDP test app JavaScript files can be edited through the same deterministic existing-file path.
+- `python_programming`, `javascript_programming`, and `tcp_udp_app` can be treated as `edit_proven` for explicit script-file edits.
+- `python_programming`, `javascript_programming`, and `tcp_udp_app` are `donor_backed_ready` for explicit existing-file edits because the proof gate has sample, decode, parser, and editor roundtrip evidence.
+
+## What This Does Not Prove
+
+- It does not create Network Controller projects, apps, or files.
+- It does not mutate Blockly visual graphs beyond inventory/report truth.
+- It does not create or run VM/IOx workloads.
+- It does not synthesize controller policies, REST workflows, or TCP/UDP applications from a broad prompt.
+- It does not make any automation/controller feature `generate_ready`.
+
+## Explicit Edit Shape
+
+```text
+set "python" script app "New Project (Python)" file "main.py" content "print(\"ok\")"
+set "javascript" script app "New Project (JavaScript)" file "main.js" content "console.log(\"ok\")"
+set "PC0" script app "tcpServer" file "tcpServer.js" content "console.log(\"tcp\")"
+```
+
+The editor refuses ambiguous or missing device/app/file targets. It replaces only existing file content and does not guess app names or create new programming surfaces.
+
+## Product Contract
+
+- `python_programming`, `javascript_programming`, and `tcp_udp_app` can report `edit_supported=true` and `donor_backed_ready=true` only for explicit existing-file edit commands.
+- `network_controller`, `blockly_programming`, and `vm_iox` remain report-only.
+- All automation/controller features keep `generate_supported=false` until separate donor-backed acceptance evidence exists.

package/docs/campus-donor-proof.md

@@ -0,0 +1,103 @@
+# Campus Donor Proof
+
+## Proof Goal
+
+Show one honest public proof artifact for the canonical `campus` family without claiming full synthetic generation.
+
+## Real Donor Artifact
+
+- registry entry: `complex_campus_master_edit_v4.pkt`
+- proof source: a local donor file matching that registry entry name in the ignored working `output/` area
+- runtime mode used for the proof: Windows Packet Tracer 9.0 with an external bridge override
+
+## Inventory Smoke Result
+
+The matched donor file decoded and inventoried successfully.
+
+Observed topology summary:
+
+- `6` switches
+- `1` router
+- `2` servers
+- `5` printers
+- `5` wireless routers
+- `40` PCs
+- `58` links
+- services present
+- wireless present
+- VLANs present
+
+Observed management and security details:
+
+- management VLANs are present on the campus switches
+- Telnet is enabled on the campus switches
+- ACL `MGMT_ONLY` is present on the router
+- DHCP pools, DNS, email, syslog, AAA, and wireless service state are visible in inventory
+
+## Planner Result for a Generalized Campus Prompt
+
+Prompt used for the public proof check:
+
+`6 sobeli kampus sebekesi qur, VLAN 10 20 30 40 50 60 ve management VLAN 99 yarat, telnet, acl, nat, wireless ap ve printer elave et`
+
+Observed decision result:
+
+- `family=campus`
+- `status=blocked_by_donor_selection`
+- `selection_failure_type=viable_donor_found_but_acceptance_weak`
+- `best_available_donor_class=campus/core`
+- `best_rejected_donor_class=campus/core`
+- `primary_rejection_layer=donor`
+- `primary_rejection_code=layout_reuse_too_weak`
+- `candidate_counts.selected=0`
+- `candidate_counts.filtered=269`
+
+Top rejection reasons:
+
+- donor graph has no reusable link pairs for the requested topology
+- sample reuses too little of the requested link skeleton
+- `missing_link_pairs:6`
+
+Closest rejected donor summary:
+
+- the closest donor class is still `campus/core`
+- registry-backed donor evidence exists for that class
+- prompt-level selection still refuses it because reusable link skeleton quality is too weak
+
+## What This Proves
+
+- a real donor path exists for the canonical campus proof artifact
+- donor inventory works
+- planner refusal is still explicit and deterministic
+- the blocker for the generalized campus prompt is donor selection quality
+
+## What This Does Not Prove
+
+- it does not prove synthetic campus generation is solved
+- it does not prove every campus prompt is generate-ready
+- it does not prove runtime was the blocker for this prompt
+- it does not make registry-backed donor evidence equivalent to prompt-level donor selection
+
+## Interpretation
+
+This proof means two different things at once:
+
+- a real campus donor artifact exists and inventories correctly
+- the current planner still refuses to select a donor for the larger six-department campus prompt when the reusable link skeleton is too weak
+
+That refusal is the correct product behavior. In this proof run, runtime was not the blocking layer. Donor selection quality was.
+
+The shorthand campus classifier should still resolve this prompt family as `campus`; the refusal should be read as donor-limited campus semantics, not as a service-heavy family drift.
+
+## Public Message Guardrail
+
+Say:
+
+- donor-backed campus donor proof exists
+- real donor inventory works
+- generalized campus generation can still be donor-limited
+
+Do not say:
+
+- the campus prompt is fully generate-ready
+- the donor proof implies synthetic topology generation is solved

package/docs/curated-donor-registry.md

@@ -33,6 +33,25 @@ The current seeded entries are based on known working example artifacts:
 
 These entries become active when a donor root contains matching relative paths or filenames.
 
+Current public proof reference:
+
+- `docs/campus-donor-proof.md`
+- `docs/home-iot-donor-proof.md`
+- `docs/wan-security-donor-proof.md`
+
+This is intentionally separate from the registry file. A registry-backed donor may still be refused for a generalized prompt if the reusable link skeleton is too weak.
+
+Important proof semantics:
+
+- registry entry exists
+  Means the donor metadata is explicit and checked in.
+- inventory-proof donor exists
+  Means a real donor artifact matched that entry and passed inventory smoke.
+- selected donor exists
+  Means prompt-level selector and runtime constraints both accepted it for the current request.
+
+Those are related, but they are not the same claim.
+
 ## Promotion Rules
 
 - `reference_only` never becomes the final selected donor
@@ -40,6 +59,17 @@ These entries become active when a donor root contains matching relative paths o
 - registry-backed metadata overrides inferred metadata where the registry is more explicit
 - validation can still demote a registry entry if the actual donor is blocked or incompatible
 
+## Remote Sample Promotion Rules
+
+GitHub sample ingestion is a local developer workflow, not a direct registry promotion path.
+
+- remote `.pkt` and `.pka` files are imported only into `output/remote-import-cache`
+- unknown, missing, or non-permissive license metadata stays `reference_only`
+- permissive-license metadata can only create a `validated_curated` candidate after decode and inventory validation
+- decode-fail samples can be recorded in `remote-sample-audit.json`, but they cannot create donor eligibility
+- no remote sample becomes `acceptance_verified_curated` without checked acceptance fixtures and proof notes
+- raw remote `.pkt` files are not committed and are not packed into npm artifacts
+
 ## Evidence Sources
 
 Selected donor summaries distinguish:
@@ -49,3 +79,10 @@ Selected donor summaries distinguish:
 - mixed `registry+inferred` evidence
 
 This is important for auditability and release messaging.
+
+Rejected donor summaries should preserve the same distinction. A closest rejected donor class can still be registry-backed while prompt-level donor selection remains blocked by:
+
+- `layout_reuse_too_weak`
+- `acceptance_evidence_too_weak`
+- `archetype_misaligned`
+- `runtime_subtree_missing`

package/docs/generate-ready-pilot-design.md

@@ -0,0 +1,30 @@
+# Generate-Ready Pilot Design
+
+This is a design artifact only. It does not enable `generate_ready`.
+
+## Candidate
+
+The first safe pilot should use a narrow campus or service-heavy flow that already has fixture and donor evidence. The preferred pilot is `campus_core_complex` with a single `campus/core` donor class.
+
+## Required Gate
+
+The pilot can only move to implementation when all of these are true:
+
+- exactly one scenario family is in scope
+- exactly one donor class is allowed
+- exactly one fixture name is used as the regression truth source
+- target inventory is deterministic
+- final `.pkt` apply remains `single-donor`
+- acceptance JSON proves openability, inventory expectations, parity expectations, and decision status
+
+## Explicit Non-Goals
+
+- no L2/QoS generate-ready pilot
+- no ASA/security generate-ready pilot
+- no WLC/controller generate-ready pilot
+- no broad topology synthesis
+- no fallback guessed output when donor selection or acceptance is weak
+
+## Next Step
+
+Before implementation, add a short acceptance fixture proposal that names the donor path, expected inventory excerpt, expected parity excerpt, and the refusal condition when that donor is absent.

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

@@ -0,0 +1,45 @@
+# GitHub Launch Ops for `v0.2.1`
+
+## Current Status
+
+- npm package `packet-tracer-skill@0.2.1` is already published
+- release body source is ready: `docs/release-notes-0.2.1.md`
+- About text and Topics source are ready: `docs/github-metadata.md`
+- hero visual is fixed: `examples/screenshots/complex_campus_master_edit_v4.png`
+- GitHub release object and Discussions setup still require manual UI work because `gh` is not installed in the current environment
+
+## Exact GitHub Release Steps
+
+1. Ensure tag `v0.2.1` 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.1`.
+4. Use title `v0.2.1`.
+5. Paste the body from `docs/release-notes-0.2.1.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`:
+
+- `Final About Text`
+- `Final Topics`
+
+Do not rewrite these ad hoc in the UI. The doc is the source of truth.
+
+## Discussions
+
+Enable Discussions and create these categories:
+
+- `Showcase`
+- `Q&A`
+- `Donor Requests`
+- `Capability Roadmap`
+
+## Launch Message Sources
+
+Use:
+
+- `docs/release-notes-0.2.1.md` for the release body
+- `docs/launch-announcement-0.2.1.md` for the npm/GitHub/social wording
+- `docs/hero-demo-plan.md` for the screenshot caption and demo claim guardrails

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/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/industrial-programming-proof.md

@@ -0,0 +1,48 @@
+# Industrial Programming Proof
+
+This proof covers the narrow Packet Tracer programming surface promoted after the `0.2.2` baseline. It is intentionally donor-backed edit readiness, not generate-first support.
+
+## What This Proves
+
+- Real HTTP and Real WebSocket samples expose stable existing script files in Packet Tracer XML.
+- Inventory can report programming apps without dumping full source code.
+- Explicit quoted commands can replace an existing script file when device, app, and file names are unique.
+- Real HTTP and Real WebSocket can be treated as `edit_proven` for deterministic script-file edits.
+- Real HTTP and Real WebSocket are the first `donor_backed_ready` atlas entries because they pass a validated proof gate: sample-backed inventory, decode evidence, explicit target resolution, and editor roundtrip proof.
+
+## What This Does Not Prove
+
+- It does not claim broad Industrial IoT topology generation.
+- It does not create new apps, new files, MQTT brokers, WebSocket servers, or Real HTTP services.
+- It does not claim MQTT protocol mutation, Profinet, PTP, L2NAT, CyberObserver, or industrial firewall edit support.
+- It does not make any industrial programming feature `generate_ready`.
+- It does not create a new app or file when a donor lacks the named script target.
+
+## Explicit Edit Command Shape
+
+```text
+set "Py: real http server 2" script app "New Project (Python)" file "main.py" content "from realhttp import *\nprint(\"ok\")"
+set "WebSockets Client" script app "ws client (Python)" file "main.py" content "from realhttp import *\nclient = RealWSClient()\nprint(\"ok\")"
+```
+
+The command is quoted on purpose. Packet Tracer app and device names often contain spaces, punctuation, and parentheses. Unquoted script mutation is not supported.
+
+## Donor-Backed Readiness Boundary
+
+`donor_backed_ready` means the skill can safely apply an explicit existing-file script edit when the donor already contains the named device, app, and file. It does not mean broad prompt generation is ready.
+
+Readiness requires all of these to be true:
+
+- the feature is `real_http` or `real_websocket`
+- the command quotes a device name, app name, existing file name, and replacement content
+- inventory resolves exactly one matching target
+- the editor roundtrip test proves the file content can be replaced and decoded again
+- no new app, new file, MQTT broker, HTTP service, or WebSocket service is synthesized
+
+## Public Contract
+
+- `real_http`, `real_websocket`, `python_programming`, and `javascript_programming` can report `edit_supported=true` only for explicit existing-file edits.
+- `real_http` and `real_websocket` can report `donor_backed_ready=true` for explicit existing-file edits.
+- `generate_supported=false` remains the expected result.
+- `generate_mismatch_reason=supported_in_edit_only` is the intended parity wording.
+- `mqtt`, `visual_scripting`, `ptp`, `profinet`, `l2nat`, `cyberobserver`, and `industrial_firewall` remain report-only until separate roundtrip proof exists.

package/docs/ipv4-routing-management-proof.md

@@ -0,0 +1,37 @@
+# IPv4 Routing and IOS Management Proof
+
+This proof wave uses the local user-supplied `pkt_examples` corpus as evidence input, not as public package content. The corpus contains many decodeable Packet Tracer labs with IPv4 routing, NAT/PAT, SSH, NTP, syslog, DHCP relay, and classic CCNA management patterns.
+
+## What Is Edit-Proven
+
+The supported subset is explicit IOS `RUNNINGCONFIG` mutation only:
+
+- OSPFv2 via `router ospf <process>` with `network <network> <wildcard> area <area>`
+- `router eigrp <asn>` with IPv4 `network` and optional `no auto-summary`
+- `router rip` with `version 2`, IPv4 `network`, and optional `no auto-summary`
+- `ip route <network> <mask> <next-hop>` including default route
+- interface-level `ip helper-address`
+- interface-level `ip nat inside` and `ip nat outside`
+- `ip nat inside source static <inside-local> <inside-global>`
+- PAT overload with `ip nat inside source list <acl> interface <interface> overload`
+- IOS SSH setup with domain, username/password, RSA modulus, and `ip ssh version 2`
+- IOS `ntp server` and `logging host`
+
+## What This Proves
+
+- The parser can classify IPv4 routing and management prompts as `ipv4_routing_management`.
+- Explicit commands produce deterministic router operations.
+- Existing IOS text config surfaces can roundtrip these command shapes.
+- Parity can show these capabilities as `edit_supported=true`, `generate_supported=false`, and `generate_mismatch_reason=supported_in_edit_only`.
+- Local sample audit can summarize user-supplied `.pkt/.pka` evidence without committing raw Packet Tracer files.
+
+## What This Does Not Prove
+
+- It does not make any IPv4 routing, NAT, or IOS management capability `generate_ready`.
+- It does not synthesize topology, links, ACL objects, NAT pools, route convergence, or lab scoring.
+- It does not promote local `pkt_examples` files into curated public donors.
+- It does not mutate GUI/internal Packet Tracer state.
+
+## Safe Next Step
+
+The next promotion step is donor-backed readiness for a narrow single-donor IPv4 routing fixture, only after selected-donor evidence, deterministic targets, and acceptance JSON prove the resulting `.pkt` opens and matches expected inventory/parity.

package/docs/l2-resiliency-bgp-proof.md

@@ -0,0 +1,60 @@
+# L2 Resiliency + BGP Proof Wave
+
+This proof wave uses the local user-supplied `pkt_examples` corpus as evidence input only. Raw `.pkt` files, imported caches, and `output/pkt_examples_audit.json` are not package or repository artifacts.
+
+## What Is Covered
+
+The wave adds parser, inventory, catalog, atlas, and parity truth for:
+
+- `bgp`
+- `stp`
+- `rstp`
+- `etherchannel`
+- `lacp`
+- `pagp`
+- `vtp`
+- `dtp`
+
+These capabilities are constrained to IOS text configuration surfaces. They are not broad topology generation features.
+
+## Explicit Edit Commands
+
+Supported edit-proof command shapes:
+
+```powershell
+python scripts/generate_pkt.py --parity-report "set R1 bgp 65001 neighbor 10.0.0.2 remote-as 65002 network 192.168.1.0 mask 255.255.255.0"
+python scripts/generate_pkt.py --parity-report "set SW1 stp mode rapid-pvst vlan 10 root primary"
+python scripts/generate_pkt.py --parity-report "set SW1 etherchannel 1 mode active interfaces FastEthernet0/1 FastEthernet0/2"
+python scripts/generate_pkt.py --parity-report "set SW1 etherchannel 2 mode desirable interfaces FastEthernet0/3 FastEthernet0/4"
+python scripts/generate_pkt.py --parity-report "set SW1 vtp domain CAMPUS mode server version 2"
+python scripts/generate_pkt.py --parity-report "set SW1 dtp interface FastEthernet0/1 mode dynamic desirable"
+```
+
+## Target Rules
+
+- The target device name must be explicit.
+- Interface names must be explicit where an interface command is used.
+- Only existing device configuration text is mutated.
+- No GUI/internal Packet Tracer state is guessed.
+- No links, modules, devices, or topology shape are synthesized in this wave.
+
+## What This Proves
+
+- BGP neighbor/network IOS text can be parsed and written deterministically.
+- The editor writes a `router bgp` block with explicit `neighbor ... remote-as` and optional `network ... mask` lines.
+- STP/RSTP can be detected separately from SPAN/RSPAN through explicit `spanning-tree` lines.
+- EtherChannel can be represented through explicit `channel-group` and `Port-channel` text.
+- LACP/PAgP are derived from explicit EtherChannel modes.
+- VTP and DTP line shapes can be parsed, inventoried, and roundtripped as IOS text.
+
+## What This Does Not Prove
+
+- It does not prove full BGP peering convergence.
+- It does not prove STP state simulation correctness.
+- It does not create or validate physical redundant links.
+- It does not make these capabilities `donor_backed_ready`.
+- It does not make any of these capabilities `generate_ready`.
+
+## Current Product Status
+
+The atlas status for this wave is `edit_proven` when roundtrip tests exist. `generate_ready=0` remains intentional until a single-donor acceptance fixture proves a strict safe-open generate path.

package/docs/l2-security-qos-proof.md

@@ -0,0 +1,59 @@
+# L2 Security and QoS Proof
+
+This proof records the `0.2.3` candidate L2 security/QoS edit-proven subset. It is intentionally narrow: the skill can append deterministic IOS-style switch configuration lines for explicitly named targets, but it does not synthesize a full NAC or QoS design from a broad prompt.
+
+## Explicit Commands
+
+Supported explicit edit shapes:
+
+```text
+set SW1 dot1x interface FastEthernet0/1 mode auto radius 192.168.1.10 key radius123
+set SW1 qos class-map VOICE match dscp ef policy-map QOS_POLICY class VOICE priority service-policy output FastEthernet0/1
+```
+
+The dot1x command writes:
+
+```text
+aaa new-model
+dot1x system-auth-control
+radius-server host 192.168.1.10 key radius123
+interface FastEthernet0/1
+ authentication port-control auto
+ dot1x pae authenticator
+```
+
+The QoS command writes:
+
+```text
+mls qos
+class-map match-any VOICE
+ match dscp ef
+policy-map QOS_POLICY
+ class VOICE
+  priority
+interface FastEthernet0/1
+ service-policy output QOS_POLICY
+```
+
+## Donor-Backed Readiness
+
+- `dot1x` is `donor_backed_ready` because it has parser, catalog, decode-verified sample, and editor roundtrip evidence.
+- `qos` remains `edit_proven` rather than `donor_backed_ready` because the current QoS sample evidence is path-backed but not decode-verified in the atlas gate.
+
+## What This Proves
+
+- `dot1x` and `qos` are parser-recognized as `l2_security_monitoring`.
+- Explicit dot1x and QoS commands roundtrip through Packet Tracer XML config text.
+- Parity reports mark these capabilities as `edit_supported=true`, `generate_supported=false`, and `generate_mismatch_reason=supported_in_edit_only`.
+- The feature atlas can classify dot1x as `donor_backed_ready` and QoS as `edit_proven` when the proof gate is evaluated.
+
+## What This Does Not Prove
+
+- This does not make dot1x or QoS `generate_ready`.
+- This does not create RADIUS server users, certificates, supplicant profiles, policy discovery, or end-to-end NAC validation.
+- This does not generate QoS classes from traffic intent; class-map, policy-map, direction, and interface must be explicit.
+- This does not prove every Packet Tracer switch model accepts every IOS line.
+
+## Safe Next Step
+
+The next promotion would require selected-donor proof with a reusable L2 security/monitoring skeleton and acceptance fixtures. Until then, broad prompts such as `dot1x qos policy class-map policy-map` remain report/plan evidence, while explicit commands use the edit-only path.

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.