packet-tracer-skill 0.2.2 → 0.2.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +32 -1
- package/README.md +221 -51
- package/docs/automation-controller-proof.md +35 -0
- package/docs/curated-donor-registry.md +11 -0
- package/docs/generate-ready-pilot-design.md +30 -0
- package/docs/industrial-programming-proof.md +48 -0
- package/docs/ipv4-routing-management-proof.md +37 -0
- package/docs/l2-resiliency-bgp-proof.md +60 -0
- package/docs/l2-security-qos-proof.md +59 -0
- package/docs/packet-tracer-feature-gap-atlas.md +172 -15
- package/docs/release-checklist.md +13 -8
- package/docs/release-notes-0.2.2.md +1 -1
- package/docs/release-notes-0.2.3.md +59 -0
- package/docs/security-edge-deepening-proof.md +65 -0
- package/docs/voice-collaboration-proof.md +38 -0
- package/docs/wan-security-donor-proof.md +20 -3
- package/package.json +10 -1
- package/references/packettracer-feature-atlas.json +67 -17
- package/scripts/coverage_matrix.py +505 -12
- package/scripts/feature_atlas.py +65 -1
- package/scripts/generate_pkt.py +161 -3
- package/scripts/intent_parser.py +521 -2
- package/scripts/pkt_editor.py +477 -0
- package/scripts/remote_search.py +197 -21
- package/scripts/sample_catalog.py +57 -2
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# L2 Resiliency + BGP Proof Wave
|
|
2
|
+
|
|
3
|
+
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.
|
|
4
|
+
|
|
5
|
+
## What Is Covered
|
|
6
|
+
|
|
7
|
+
The wave adds parser, inventory, catalog, atlas, and parity truth for:
|
|
8
|
+
|
|
9
|
+
- `bgp`
|
|
10
|
+
- `stp`
|
|
11
|
+
- `rstp`
|
|
12
|
+
- `etherchannel`
|
|
13
|
+
- `lacp`
|
|
14
|
+
- `pagp`
|
|
15
|
+
- `vtp`
|
|
16
|
+
- `dtp`
|
|
17
|
+
|
|
18
|
+
These capabilities are constrained to IOS text configuration surfaces. They are not broad topology generation features.
|
|
19
|
+
|
|
20
|
+
## Explicit Edit Commands
|
|
21
|
+
|
|
22
|
+
Supported edit-proof command shapes:
|
|
23
|
+
|
|
24
|
+
```powershell
|
|
25
|
+
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"
|
|
26
|
+
python scripts/generate_pkt.py --parity-report "set SW1 stp mode rapid-pvst vlan 10 root primary"
|
|
27
|
+
python scripts/generate_pkt.py --parity-report "set SW1 etherchannel 1 mode active interfaces FastEthernet0/1 FastEthernet0/2"
|
|
28
|
+
python scripts/generate_pkt.py --parity-report "set SW1 etherchannel 2 mode desirable interfaces FastEthernet0/3 FastEthernet0/4"
|
|
29
|
+
python scripts/generate_pkt.py --parity-report "set SW1 vtp domain CAMPUS mode server version 2"
|
|
30
|
+
python scripts/generate_pkt.py --parity-report "set SW1 dtp interface FastEthernet0/1 mode dynamic desirable"
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## Target Rules
|
|
34
|
+
|
|
35
|
+
- The target device name must be explicit.
|
|
36
|
+
- Interface names must be explicit where an interface command is used.
|
|
37
|
+
- Only existing device configuration text is mutated.
|
|
38
|
+
- No GUI/internal Packet Tracer state is guessed.
|
|
39
|
+
- No links, modules, devices, or topology shape are synthesized in this wave.
|
|
40
|
+
|
|
41
|
+
## What This Proves
|
|
42
|
+
|
|
43
|
+
- BGP neighbor/network IOS text can be parsed and written deterministically.
|
|
44
|
+
- The editor writes a `router bgp` block with explicit `neighbor ... remote-as` and optional `network ... mask` lines.
|
|
45
|
+
- STP/RSTP can be detected separately from SPAN/RSPAN through explicit `spanning-tree` lines.
|
|
46
|
+
- EtherChannel can be represented through explicit `channel-group` and `Port-channel` text.
|
|
47
|
+
- LACP/PAgP are derived from explicit EtherChannel modes.
|
|
48
|
+
- VTP and DTP line shapes can be parsed, inventoried, and roundtripped as IOS text.
|
|
49
|
+
|
|
50
|
+
## What This Does Not Prove
|
|
51
|
+
|
|
52
|
+
- It does not prove full BGP peering convergence.
|
|
53
|
+
- It does not prove STP state simulation correctness.
|
|
54
|
+
- It does not create or validate physical redundant links.
|
|
55
|
+
- It does not make these capabilities `donor_backed_ready`.
|
|
56
|
+
- It does not make any of these capabilities `generate_ready`.
|
|
57
|
+
|
|
58
|
+
## Current Product Status
|
|
59
|
+
|
|
60
|
+
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.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# L2 Security and QoS Proof
|
|
2
|
+
|
|
3
|
+
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.
|
|
4
|
+
|
|
5
|
+
## Explicit Commands
|
|
6
|
+
|
|
7
|
+
Supported explicit edit shapes:
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
set SW1 dot1x interface FastEthernet0/1 mode auto radius 192.168.1.10 key radius123
|
|
11
|
+
set SW1 qos class-map VOICE match dscp ef policy-map QOS_POLICY class VOICE priority service-policy output FastEthernet0/1
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
The dot1x command writes:
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
aaa new-model
|
|
18
|
+
dot1x system-auth-control
|
|
19
|
+
radius-server host 192.168.1.10 key radius123
|
|
20
|
+
interface FastEthernet0/1
|
|
21
|
+
authentication port-control auto
|
|
22
|
+
dot1x pae authenticator
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
The QoS command writes:
|
|
26
|
+
|
|
27
|
+
```text
|
|
28
|
+
mls qos
|
|
29
|
+
class-map match-any VOICE
|
|
30
|
+
match dscp ef
|
|
31
|
+
policy-map QOS_POLICY
|
|
32
|
+
class VOICE
|
|
33
|
+
priority
|
|
34
|
+
interface FastEthernet0/1
|
|
35
|
+
service-policy output QOS_POLICY
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Donor-Backed Readiness
|
|
39
|
+
|
|
40
|
+
- `dot1x` is `donor_backed_ready` because it has parser, catalog, decode-verified sample, and editor roundtrip evidence.
|
|
41
|
+
- `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.
|
|
42
|
+
|
|
43
|
+
## What This Proves
|
|
44
|
+
|
|
45
|
+
- `dot1x` and `qos` are parser-recognized as `l2_security_monitoring`.
|
|
46
|
+
- Explicit dot1x and QoS commands roundtrip through Packet Tracer XML config text.
|
|
47
|
+
- Parity reports mark these capabilities as `edit_supported=true`, `generate_supported=false`, and `generate_mismatch_reason=supported_in_edit_only`.
|
|
48
|
+
- The feature atlas can classify dot1x as `donor_backed_ready` and QoS as `edit_proven` when the proof gate is evaluated.
|
|
49
|
+
|
|
50
|
+
## What This Does Not Prove
|
|
51
|
+
|
|
52
|
+
- This does not make dot1x or QoS `generate_ready`.
|
|
53
|
+
- This does not create RADIUS server users, certificates, supplicant profiles, policy discovery, or end-to-end NAC validation.
|
|
54
|
+
- This does not generate QoS classes from traffic intent; class-map, policy-map, direction, and interface must be explicit.
|
|
55
|
+
- This does not prove every Packet Tracer switch model accepts every IOS line.
|
|
56
|
+
|
|
57
|
+
## Safe Next Step
|
|
58
|
+
|
|
59
|
+
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.
|
|
@@ -7,21 +7,33 @@ It is intentionally conservative:
|
|
|
7
7
|
- `inventory_known` means a Packet Tracer sample or path proves the feature exists.
|
|
8
8
|
- `report_supported` means the skill can recognize and report the feature without claiming mutation support.
|
|
9
9
|
- `edit_proven` requires a roundtrip editor test.
|
|
10
|
-
- `donor_backed_ready` requires selected-donor evidence.
|
|
10
|
+
- `donor_backed_ready` requires selected-donor evidence or a validated proof-linked explicit edit gate with sample, decode, and roundtrip evidence.
|
|
11
11
|
- `generate_ready` requires acceptance-backed generate behavior.
|
|
12
12
|
|
|
13
13
|
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.
|
|
14
14
|
|
|
15
|
-
##
|
|
15
|
+
## Remote Sample Evidence
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
GitHub `.pkt` repositories can add discovery evidence, but they do not automatically change feature maturity.
|
|
18
18
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
23
|
-
-
|
|
24
|
-
|
|
19
|
+
Remote sample evidence is treated in three layers:
|
|
20
|
+
|
|
21
|
+
- sample-path evidence: a public repo path suggests a Packet Tracer feature exists, but the file may still fail decode or validation
|
|
22
|
+
- decode/inventory evidence: a locally cached sample opens through the decoder and produces feature tags
|
|
23
|
+
- proof evidence: an explicit editor roundtrip or acceptance fixture proves a safe operation shape
|
|
24
|
+
|
|
25
|
+
`output/remote-import-cache/remote-sample-audit.json` records repo URL, license metadata, imported file counts, decode success/failure counts, detected feature tags, license-based candidate promotion status, and decode-gated validation status. Unknown-license repositories remain `reference_only`. Permissive-license repositories only become curated candidates after local decode and inventory validation. Raw remote `.pkt` files are never a checked-in truth source.
|
|
26
|
+
|
|
27
|
+
## First Donor-Backed Edit Readiness Wave
|
|
28
|
+
|
|
29
|
+
The first promotion wave is `ipv6_routing`. The following subset can move beyond report-only when explicit router/interface targets or proof-linked IPv6/routing edit evidence exists:
|
|
30
|
+
|
|
31
|
+
- IPv6 interface/SLAAC config remains edit-proven.
|
|
32
|
+
- DHCPv6 stateful pool binding remains edit-proven until decode-verified sample evidence is available.
|
|
33
|
+
- OSPFv3 interface routing is donor-backed ready for explicit edit paths.
|
|
34
|
+
- EIGRP IPv6 interface routing is donor-backed ready for explicit edit paths.
|
|
35
|
+
- RIPng interface routing is donor-backed ready for explicit edit paths.
|
|
36
|
+
- IPv6 HSRP virtual address is donor-backed ready for explicit edit paths.
|
|
25
37
|
|
|
26
38
|
IPv6 tunneling, ISATAP, prefix delegation, and AAAA DNS remain report-first until separate donor-backed editor proof exists.
|
|
27
39
|
|
|
@@ -56,23 +68,168 @@ SSID. They still report `generate_supported=false` and
|
|
|
56
68
|
WLC/controller workflows, Meraki, cellular/5G, Bluetooth, beamforming, and
|
|
57
69
|
guest Wi-Fi remain report-only until separate donor-backed editor proof exists.
|
|
58
70
|
|
|
71
|
+
## Fourth Edit-Proven Wave
|
|
72
|
+
|
|
73
|
+
The fourth promotion wave is `wan_security_edge`. This wave promotes only
|
|
74
|
+
explicit, deterministic router edit commands:
|
|
75
|
+
|
|
76
|
+
- GRE tunnel basics
|
|
77
|
+
- PPP serial encapsulation
|
|
78
|
+
- IPSec transform-set lines
|
|
79
|
+
- site-to-site VPN crypto-map skeleton binding
|
|
80
|
+
|
|
81
|
+
These capabilities can report `edit_supported=true` only when the prompt names
|
|
82
|
+
the router, interface or tunnel, peer/source/destination, and required crypto
|
|
83
|
+
objects. They still report `generate_supported=false` and
|
|
84
|
+
`generate_mismatch_reason=supported_in_edit_only`.
|
|
85
|
+
|
|
86
|
+
ASA ACL/NAT, service policies, clientless VPN, CBAC, ZFW, security-edge device
|
|
87
|
+
mutation, and multilayer switching remain report-only in this wave until separate
|
|
88
|
+
donor-backed editor proof exists.
|
|
89
|
+
|
|
90
|
+
## Fifth Donor-Backed Edit Readiness Wave
|
|
91
|
+
|
|
92
|
+
The fifth promotion wave is `industrial_iot` programming. This wave promotes
|
|
93
|
+
only existing script-file replacement for Real HTTP and Real WebSocket samples:
|
|
94
|
+
|
|
95
|
+
- Real HTTP Python script file replacement
|
|
96
|
+
- Real WebSocket Python/JavaScript script file replacement
|
|
97
|
+
- programming inventory with hashes and lengths instead of source dumps
|
|
98
|
+
|
|
99
|
+
These capabilities can report `edit_supported=true` and
|
|
100
|
+
`donor_backed_ready=true` only when the prompt quotes the device name, app name,
|
|
101
|
+
and existing file name. They still report `generate_supported=false` and
|
|
102
|
+
`generate_mismatch_reason=supported_in_edit_only`.
|
|
103
|
+
|
|
104
|
+
MQTT protocol mutation, visual scripting generation, PTP, Profinet, L2NAT,
|
|
105
|
+
CyberObserver, and industrial firewall workflows remain report-only until
|
|
106
|
+
separate donor-backed editor proof exists.
|
|
107
|
+
|
|
108
|
+
## Sixth Donor-Backed Edit Readiness Wave
|
|
109
|
+
|
|
110
|
+
The sixth promotion wave is `voice_collaboration`. This wave promotes only
|
|
111
|
+
explicit IOS voice configuration lines on an existing router config surface:
|
|
112
|
+
|
|
113
|
+
- `telephony-service` source address, SCCP port, max ephones, and max DNs
|
|
114
|
+
- `ephone-dn` extension number lines
|
|
115
|
+
- `ephone` MAC and button assignment lines
|
|
116
|
+
- `dial-peer voice` destination-pattern and session-target lines
|
|
117
|
+
|
|
118
|
+
These capabilities can report `edit_supported=true` and
|
|
119
|
+
`donor_backed_ready=true` only when the prompt names the router and the voice
|
|
120
|
+
object identifiers or values. They still report `generate_supported=false` and
|
|
121
|
+
`generate_mismatch_reason=supported_in_edit_only`.
|
|
122
|
+
|
|
123
|
+
IP phone GUI internals, Linksys voice GUI mutation, Call Manager synthesis, and
|
|
124
|
+
broad VoIP topology generation remain report-only until separate donor-backed
|
|
125
|
+
editor proof exists.
|
|
126
|
+
|
|
127
|
+
## Seventh Donor-Backed Edit Readiness Wave
|
|
128
|
+
|
|
129
|
+
The seventh promotion wave is `automation_controller`. This wave promotes only
|
|
130
|
+
existing script-file replacement on Packet Tracer programming samples:
|
|
131
|
+
|
|
132
|
+
- Python app file replacement
|
|
133
|
+
- JavaScript app file replacement
|
|
134
|
+
- TCP/UDP test app JavaScript file replacement
|
|
135
|
+
- programming inventory with hashes and lengths instead of source dumps
|
|
136
|
+
|
|
137
|
+
These capabilities can report `edit_supported=true` and
|
|
138
|
+
`donor_backed_ready=true` only when the prompt quotes the device name, app name,
|
|
139
|
+
and existing file name. They still report `generate_supported=false` and
|
|
140
|
+
`generate_mismatch_reason=supported_in_edit_only`.
|
|
141
|
+
|
|
142
|
+
Network Controller GUI workflows, Blockly visual graph mutation, VM/IOx runtime
|
|
143
|
+
creation, and broad controller/application generation remain report-only until
|
|
144
|
+
separate donor-backed editor proof exists.
|
|
145
|
+
|
|
146
|
+
## Eighth Donor-Backed Edit Readiness Wave
|
|
147
|
+
|
|
148
|
+
The eighth promotion wave is the `0.2.3` candidate L2/security proof hardening.
|
|
149
|
+
This wave promotes only deterministic IOS line edits:
|
|
150
|
+
|
|
151
|
+
- 802.1X/NAC switch config using `aaa new-model`, `dot1x system-auth-control`,
|
|
152
|
+
`authentication port-control`, and optional `radius-server host`
|
|
153
|
+
- QoS switch config using explicit `class-map`, `policy-map`, and
|
|
154
|
+
`service-policy input/output`
|
|
155
|
+
- router CBAC using `ip inspect name` plus interface-level `ip inspect`
|
|
156
|
+
- router ZFW using `zone security`, `zone-pair security`, and
|
|
157
|
+
`policy-map type inspect`
|
|
158
|
+
|
|
159
|
+
These capabilities can report `edit_supported=true` only for explicit commands
|
|
160
|
+
with deterministic device/interface/object names. Dot1x and ZFW can also report
|
|
161
|
+
`donor_backed_ready=true` because they have decode-verified sample evidence.
|
|
162
|
+
QoS and CBAC remain `edit_proven` until decode-verified sample evidence is added.
|
|
163
|
+
All four still report `generate_supported=false` and
|
|
164
|
+
`generate_mismatch_reason=supported_in_edit_only`.
|
|
165
|
+
|
|
166
|
+
ASA ACL/NAT, ASA service-policy, clientless VPN, sniffer workflows, broad NAC,
|
|
167
|
+
and broad QoS design remain report-only until separate donor-backed editor proof
|
|
168
|
+
exists.
|
|
169
|
+
|
|
170
|
+
## Ninth Edit-Proven Wave
|
|
171
|
+
|
|
172
|
+
The ninth promotion wave is `l2_resiliency_routing`. This wave uses the local
|
|
173
|
+
user-supplied `pkt_examples` corpus as evidence input and promotes only explicit
|
|
174
|
+
IOS line edits:
|
|
175
|
+
|
|
176
|
+
- BGP `router bgp`, `neighbor remote-as`, and optional `network mask` lines
|
|
177
|
+
- STP/RSTP `spanning-tree mode` and VLAN root lines
|
|
178
|
+
- EtherChannel `channel-group` and `Port-channel` lines
|
|
179
|
+
- LACP/PAgP mode derivation from explicit EtherChannel modes
|
|
180
|
+
- VTP domain/mode/version lines
|
|
181
|
+
- DTP dynamic switchport mode lines
|
|
182
|
+
|
|
183
|
+
These capabilities can report `edit_supported=true` only for explicit commands
|
|
184
|
+
with deterministic router/switch/interface names. They do not report
|
|
185
|
+
`donor_backed_ready=true` yet, because this wave does not add selected-donor
|
|
186
|
+
acceptance proof. They still report `generate_supported=false` and
|
|
187
|
+
`generate_mismatch_reason=supported_in_edit_only`.
|
|
188
|
+
|
|
189
|
+
`spanning-tree` evidence is intentionally separated from SPAN/RSPAN. STP/RSTP
|
|
190
|
+
must not create the `span` capability; SPAN remains tied to monitor-session style
|
|
191
|
+
config or explicit SPAN/RSPAN prompts.
|
|
192
|
+
|
|
193
|
+
## Tenth Edit-Proven Wave
|
|
194
|
+
|
|
195
|
+
The tenth promotion wave is `ipv4_routing_management`. This wave also uses the
|
|
196
|
+
local user-supplied `pkt_examples` corpus as evidence input and promotes only
|
|
197
|
+
explicit IOS line edits:
|
|
198
|
+
|
|
199
|
+
- OSPFv2, EIGRP IPv4, and RIPv2 router process/network lines
|
|
200
|
+
- static and default IPv4 routes
|
|
201
|
+
- DHCP relay `ip helper-address`
|
|
202
|
+
- NAT inside/outside markers, static NAT, and PAT overload skeletons
|
|
203
|
+
- IOS SSH, NTP client, and syslog client lines
|
|
204
|
+
|
|
205
|
+
These capabilities can report `edit_supported=true` only for explicit commands
|
|
206
|
+
with deterministic router and interface names. They remain
|
|
207
|
+
`donor_backed_ready=false` and `generate_supported=false`; the local sample corpus
|
|
208
|
+
is evidence input, not a public curated donor registry.
|
|
209
|
+
|
|
59
210
|
## Current Feature Families
|
|
60
211
|
|
|
61
|
-
- `ipv6_routing`: SLAAC, DHCPv6, prefix delegation, AAAA DNS, IPv6 tunneling, ISATAP, OSPFv3, EIGRP IPv6, RIPng, HSRP.
|
|
62
|
-
- `
|
|
63
|
-
- `
|
|
212
|
+
- `ipv6_routing`: SLAAC, DHCPv6, prefix delegation, AAAA DNS, IPv6 tunneling, ISATAP, OSPFv3, EIGRP IPv6, RIPng, HSRP; OSPFv3, EIGRP IPv6, RIPng, and HSRP are donor-backed ready for explicit edit paths.
|
|
213
|
+
- `ipv4_routing_management`: OSPFv2, EIGRP IPv4, RIPv2, static/default routes, DHCP relay, static/dynamic NAT, PAT, SSH, NTP, and syslog; explicit IOS text edits are edit-proven, but not donor-backed-ready or generate-ready.
|
|
214
|
+
- `l2_resiliency_routing`: BGP, STP/RSTP, EtherChannel, LACP/PAgP, VTP, and DTP; explicit IOS text edits are edit-proven, but not donor-backed-ready or generate-ready.
|
|
215
|
+
- `l2_security_monitoring`: DHCP snooping, DAI, 802.1X/NAC, LLDP, REP, SNMP, NetFlow, SPAN/RSPAN, QoS, port security; dot1x is donor-backed ready for explicit IOS line edits, while QoS is edit-proven.
|
|
216
|
+
- `wan_security_edge`: VPN crypto-map skeleton, IPSec transform-set, GRE tunnel basics, PPP serial encapsulation, CBAC/ZFW router IOS edits, security-edge evidence, multilayer evidence.
|
|
217
|
+
- `security_edge_deepening`: ASA ACL/NAT, ASA service policy, clientless VPN, CBAC, ZFW, sniffer, IPSec variants; router ZFW is donor-backed ready, while CBAC is edit-proven.
|
|
64
218
|
- `wireless_advanced`: WLC, WPA Enterprise/RADIUS, WEP/WPA modes, guest Wi-Fi, beamforming, Meraki, 5G/cellular, Bluetooth.
|
|
65
|
-
- `automation_controller`: Network Controller, Python, JavaScript, Blockly, TCP/UDP test apps, VM/IOx samples.
|
|
66
|
-
- `voice_collaboration`: VoIP, IP phones, Call Manager-style telephony, Linksys voice.
|
|
67
|
-
- `industrial_iot`: MQTT, Real HTTP, Real WebSocket, visual scripting, PTP, Profinet, L2NAT, CyberObserver, industrial firewall.
|
|
219
|
+
- `automation_controller`: Network Controller, Python, JavaScript, Blockly, TCP/UDP test apps, VM/IOx samples; existing Python, JavaScript, and TCP/UDP script-file edits are donor-backed ready.
|
|
220
|
+
- `voice_collaboration`: VoIP, IP phones, Call Manager-style IOS telephony, Linksys voice; explicit IOS voice edits are donor-backed ready.
|
|
221
|
+
- `industrial_iot`: MQTT, Real HTTP, Real WebSocket, visual scripting, PTP, Profinet, L2NAT, CyberObserver, industrial firewall; only Real HTTP/WebSocket existing script-file edits are donor-backed ready.
|
|
68
222
|
- `physical_media_device`: coaxial, cable/DSL, central office, cell tower, power distribution, hot-swappable modules, IOS/license workflows.
|
|
69
223
|
|
|
70
224
|
## CLI
|
|
71
225
|
|
|
72
226
|
```powershell
|
|
73
227
|
python .\scripts\generate_pkt.py --feature-gap-report
|
|
228
|
+
python .\scripts\generate_pkt.py --local-sample-audit-root "C:\path\to\pkt_examples"
|
|
74
229
|
```
|
|
75
230
|
|
|
231
|
+
The default local audit artifact is `output/local-sample-audit.json`. It is ignored by git and excluded from npm packaging. Local `pkt_examples` evidence does not promote a sample into curated public truth by itself.
|
|
232
|
+
|
|
76
233
|
The report includes:
|
|
77
234
|
|
|
78
235
|
- total Packet Tracer feature groups tracked
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Release Checklist
|
|
2
2
|
|
|
3
|
-
Target release surface: `0.2.
|
|
3
|
+
Target release surface: `0.2.3` capability proof/readiness release.
|
|
4
4
|
|
|
5
5
|
## Product Contract
|
|
6
6
|
|
|
@@ -27,13 +27,17 @@ python .\scripts\runtime_doctor.py
|
|
|
27
27
|
- `files` includes docs and runtime assets needed by consumers
|
|
28
28
|
- version bump matches semver intent
|
|
29
29
|
|
|
30
|
-
## Public Artifacts
|
|
31
|
-
|
|
32
|
-
- raw `.pkt` binaries are not committed
|
|
33
|
-
-
|
|
34
|
-
-
|
|
35
|
-
-
|
|
36
|
-
-
|
|
30
|
+
## Public Artifacts
|
|
31
|
+
|
|
32
|
+
- raw `.pkt` binaries are not committed
|
|
33
|
+
- remote GitHub imports, if used, stay under `output/remote-import-cache`
|
|
34
|
+
- `output/remote-import-cache/remote-sample-audit.json` is reviewed for license, decode, and promotion status before any claim changes
|
|
35
|
+
- user-supplied local audits, if used, stay under `output/local-sample-audit.json` or another ignored `output/` path
|
|
36
|
+
- local `pkt_examples` files remain local evidence only; no raw `.pkt`, `.pka`, local audit cache, or user-supplied corpus files are packaged
|
|
37
|
+
- examples index and gallery were rebuilt
|
|
38
|
+
- screenshots are intentional and non-sensitive
|
|
39
|
+
- changelog entry is updated for `0.2.3`
|
|
40
|
+
- release notes source exists: `docs/release-notes-0.2.3.md`
|
|
37
41
|
- hero demo plan exists: `docs/hero-demo-plan.md`
|
|
38
42
|
- GitHub launch ops runbook exists: `docs/github-launch-ops-0.2.2.md`
|
|
39
43
|
- canonical donor proof exists: `docs/campus-donor-proof.md`
|
|
@@ -60,6 +64,7 @@ Only publish when:
|
|
|
60
64
|
- `package.json` version is final for the publish-preview batch
|
|
61
65
|
- doctor wording matches current runtime reality
|
|
62
66
|
- no accidental local paths leaked into tracked files
|
|
67
|
+
- no raw `.pkt`, `.pka`, or remote cache files appear in `npm pack --dry-run --json`
|
|
63
68
|
- GitHub metadata doc is final and matches README wording
|
|
64
69
|
- hero visual and release notes are ready for direct reuse
|
|
65
70
|
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
## Highlights
|
|
8
8
|
|
|
9
|
-
- README runtime instructions now use generic Twofish bridge examples instead of a user-specific
|
|
9
|
+
- README runtime instructions now use generic Twofish bridge examples instead of a user-specific local path as the default
|
|
10
10
|
- `PKT_TWOFISH_LIBRARY` and `PKT_TWOFISH_SEARCH_ROOTS` setup paths are documented separately
|
|
11
11
|
- advanced wireless prompts classify into the `wireless_advanced` family
|
|
12
12
|
- WEP and WPA Enterprise/RADIUS are represented as edit-proven only for explicit deterministic edit targets
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# packet-tracer-skill v0.2.3
|
|
2
|
+
|
|
3
|
+
`0.2.3` is a capability proof and readiness release. It expands the set of Packet Tracer features that the skill can recognize, inventory, edit with explicit deterministic commands, and report through the feature atlas without claiming broad synthetic generation.
|
|
4
|
+
|
|
5
|
+
## Highlights
|
|
6
|
+
|
|
7
|
+
- Added voice/collaboration edit proof for IOS `telephony-service`, `ephone-dn`, `ephone`, and `dial-peer voice` command shapes.
|
|
8
|
+
- Added automation/controller script-file edit proof for existing Python, JavaScript, and TCP/UDP app files.
|
|
9
|
+
- Added L2 security/QoS proof for explicit dot1x and QoS IOS switch commands.
|
|
10
|
+
- Added router security-edge proof for explicit CBAC and ZFW IOS command shapes.
|
|
11
|
+
- Added BGP + L2 resiliency proof for BGP, STP/RSTP, EtherChannel/LACP/PAgP, VTP, and DTP IOS commands.
|
|
12
|
+
- Added IPv4 routing/NAT/IOS-management proof for OSPFv2, EIGRP IPv4, RIPv2, static/default routes, DHCP relay, NAT/PAT, SSH, NTP, and syslog.
|
|
13
|
+
- Added local user-supplied Packet Tracer corpus audit with `--local-sample-audit-root`, storing audit output under ignored `output/` paths.
|
|
14
|
+
- Hardened donor-backed readiness gates so proof-linked decode, sample, parser, and editor evidence are required before readiness promotion.
|
|
15
|
+
|
|
16
|
+
## Runtime Truth
|
|
17
|
+
|
|
18
|
+
Windows-first runtime remains the supported validation posture. This release was validated with an external Twofish bridge override, but it does not claim repo-local self-contained runtime readiness.
|
|
19
|
+
|
|
20
|
+
Use:
|
|
21
|
+
|
|
22
|
+
```powershell
|
|
23
|
+
npx packet-tracer-skill --doctor
|
|
24
|
+
python .\scripts\runtime_doctor.py
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
The doctor output remains the authority for Packet Tracer install state, donor path, bridge resolution, ready operations, blocked operations, and the recommended next fix.
|
|
28
|
+
|
|
29
|
+
## Feature Atlas Truth
|
|
30
|
+
|
|
31
|
+
`generate_ready=0` remains intentional. The release improves report, edit, and donor-backed edit readiness coverage, but broad generation stays blocked until a future single-donor acceptance-backed pilot proves deterministic target inventory and acceptance JSON.
|
|
32
|
+
|
|
33
|
+
Support levels should be read in this order:
|
|
34
|
+
|
|
35
|
+
- `report_supported`: the feature is recognized and can be explained in reports.
|
|
36
|
+
- `edit_proven`: explicit command shapes have editor roundtrip evidence.
|
|
37
|
+
- `donor_backed_ready`: a proof-linked donor or selected-donor path can safely carry a narrow explicit workflow.
|
|
38
|
+
- `generate_ready`: strict scenario generation is acceptance-backed. This remains closed in `0.2.3`.
|
|
39
|
+
|
|
40
|
+
## Safety Boundaries
|
|
41
|
+
|
|
42
|
+
- No raw `.pkt` or `.pka` labs are added to the repo or npm tarball.
|
|
43
|
+
- Local `pkt_examples` evidence and remote GitHub sample imports remain evidence-only workflows.
|
|
44
|
+
- Unknown-license remote samples stay `reference_only`.
|
|
45
|
+
- ASA GUI/internal mutation, WLC/controller synthesis, broad physical/media workflows, and broad topology generation remain blocked.
|
|
46
|
+
|
|
47
|
+
## Verification
|
|
48
|
+
|
|
49
|
+
Release verification includes:
|
|
50
|
+
|
|
51
|
+
```powershell
|
|
52
|
+
python .\scripts\build_examples_index.py
|
|
53
|
+
python -m pytest tests -q
|
|
54
|
+
node --check .\bin\packet-tracer-skill.js
|
|
55
|
+
python .\scripts\generate_pkt.py --feature-gap-report
|
|
56
|
+
python .\scripts\generate_pkt.py --parity-report "campus with VLAN DHCP ACL"
|
|
57
|
+
python .\scripts\generate_pkt.py --parity-report "ospf eigrp rip static default route dhcp relay nat pat ssh ntp syslog"
|
|
58
|
+
npm pack --dry-run --json
|
|
59
|
+
```
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Security Edge Deepening Proof
|
|
2
|
+
|
|
3
|
+
This proof records the `0.2.3` candidate router-based security edge edit-proven subset. The supported surface is IOS line-based CBAC/ZFW configuration on an explicitly named router. ASA GUI/internal mutation, clientless VPN, and broad security topology generation remain blocked.
|
|
4
|
+
|
|
5
|
+
## Explicit Commands
|
|
6
|
+
|
|
7
|
+
Supported CBAC shape:
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
set R1 cbac inspect FIREWALL protocol tcp interface FastEthernet0/0 direction in
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
This writes:
|
|
14
|
+
|
|
15
|
+
```text
|
|
16
|
+
ip inspect name FIREWALL tcp
|
|
17
|
+
interface FastEthernet0/0
|
|
18
|
+
ip inspect FIREWALL in
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
Supported ZFW shapes:
|
|
22
|
+
|
|
23
|
+
```text
|
|
24
|
+
set R1 zfw zone inside interface FastEthernet0/0
|
|
25
|
+
set R1 zfw zone-pair INSIDE_OUT source inside destination outside policy POLICY1
|
|
26
|
+
set R1 zfw class-map CM_WEB match protocol http policy-map POLICY1 action inspect
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
These write:
|
|
30
|
+
|
|
31
|
+
```text
|
|
32
|
+
zone security inside
|
|
33
|
+
interface FastEthernet0/0
|
|
34
|
+
zone-member security inside
|
|
35
|
+
zone-pair security INSIDE_OUT source inside destination outside
|
|
36
|
+
service-policy type inspect POLICY1
|
|
37
|
+
class-map type inspect match-any CM_WEB
|
|
38
|
+
match protocol http
|
|
39
|
+
policy-map type inspect POLICY1
|
|
40
|
+
class type inspect CM_WEB
|
|
41
|
+
inspect
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Donor-Backed Readiness
|
|
45
|
+
|
|
46
|
+
- `zfw` is `donor_backed_ready` because it has parser, catalog, decode-verified sample, and editor roundtrip evidence.
|
|
47
|
+
- `cbac` remains `edit_proven` rather than `donor_backed_ready` because the current CBAC sample evidence is path-backed but not decode-verified in the atlas gate.
|
|
48
|
+
|
|
49
|
+
## What This Proves
|
|
50
|
+
|
|
51
|
+
- `cbac` and `zfw` are parser-recognized under the WAN/security edge family.
|
|
52
|
+
- Explicit router IOS commands roundtrip through Packet Tracer XML config text.
|
|
53
|
+
- Parity reports mark CBAC/ZFW as `edit_supported=true`, `generate_supported=false`, and `generate_mismatch_reason=supported_in_edit_only` for explicit commands.
|
|
54
|
+
- The feature atlas can classify ZFW as `donor_backed_ready` and CBAC as `edit_proven` when the proof gate is evaluated.
|
|
55
|
+
|
|
56
|
+
## What This Does Not Prove
|
|
57
|
+
|
|
58
|
+
- This does not make CBAC, ZFW, ASA ACL/NAT, ASA service policy, or clientless VPN `generate_ready`.
|
|
59
|
+
- This does not mutate ASA GUI/internal security appliance state.
|
|
60
|
+
- This does not synthesize zones, trust boundaries, NAT, VPN peers, or firewall policy from a broad prompt.
|
|
61
|
+
- ASA service-policy and clientless VPN remain report-only until exact donor-backed XML surfaces are proven.
|
|
62
|
+
|
|
63
|
+
## Safe Next Step
|
|
64
|
+
|
|
65
|
+
The next promotion should prefer router IOS CBAC/ZFW donor-backed fixtures before touching ASA internals. ASA ACL/NAT, service policy, and clientless VPN should stay report-only until a decode-backed sample and deterministic roundtrip mutation exist.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Voice Collaboration Proof
|
|
2
|
+
|
|
3
|
+
This proof covers a narrow Packet Tracer voice/collaboration wave. It is explicit-edit proof, not broad VoIP topology generation.
|
|
4
|
+
|
|
5
|
+
## What This Proves
|
|
6
|
+
|
|
7
|
+
- The Cisco `voip_local_all_phone_devices.pkt` sample exposes IP Phone, Home VoIP, Analog Phone, and router telephony evidence.
|
|
8
|
+
- Inventory can report voice devices and IOS telephony config without mutating phone GUI internals.
|
|
9
|
+
- Explicit IOS voice commands can roundtrip through Packet Tracer XML:
|
|
10
|
+
- `telephony-service`
|
|
11
|
+
- `ephone-dn`
|
|
12
|
+
- `ephone`
|
|
13
|
+
- `dial-peer voice`
|
|
14
|
+
- `voip`, `ip_phone`, and `call_manager` can be treated as `edit_proven` for explicit IOS voice edits.
|
|
15
|
+
- `voip`, `ip_phone`, and `call_manager` are `donor_backed_ready` for explicit IOS voice edits because the proof gate has sample, decode, parser, and editor roundtrip evidence.
|
|
16
|
+
|
|
17
|
+
## What This Does Not Prove
|
|
18
|
+
|
|
19
|
+
- It does not claim full Call Manager or VoIP topology generation.
|
|
20
|
+
- It does not mutate IP Phone GUI internals.
|
|
21
|
+
- It does not claim Linksys voice mutation.
|
|
22
|
+
- It does not make any voice/collaboration feature `generate_ready`.
|
|
23
|
+
|
|
24
|
+
## Explicit Edit Command Shape
|
|
25
|
+
|
|
26
|
+
```text
|
|
27
|
+
set "Router0" telephony service source-address 192.168.10.1 port 2000 max-ephones 4 max-dn 4
|
|
28
|
+
set "Router0" ephone-dn 1 number 1001
|
|
29
|
+
set "Router0" ephone 1 mac 0001.42AA.BBCC button 1:1
|
|
30
|
+
set "Router0" dial-peer voice 10 destination-pattern 2... session-target ipv4:10.0.0.2
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## Public Contract
|
|
34
|
+
|
|
35
|
+
- `voip`, `ip_phone`, and `call_manager` can report `edit_supported=true` and `donor_backed_ready=true` only for explicit IOS voice edit commands.
|
|
36
|
+
- `generate_supported=false` remains the expected result.
|
|
37
|
+
- `generate_mismatch_reason=supported_in_edit_only` is the intended parity wording.
|
|
38
|
+
- `linksys_voice` remains report-only until separate decode and editor proof exists.
|
|
@@ -24,18 +24,35 @@ The prompt must explicitly request WAN/security intent, such as VPN, IPsec, GRE,
|
|
|
24
24
|
- Packet Tracer sample inventory can identify WAN/security donor candidates.
|
|
25
25
|
- Selected-donor readiness can be represented without changing the public JSON contract.
|
|
26
26
|
- Refusal and remediation now point toward reusable ASA/cloud/serial/tunnel donor skeletons.
|
|
27
|
+
- Explicit router edit commands can roundtrip a narrow WAN/security subset:
|
|
28
|
+
- GRE tunnel interface basics
|
|
29
|
+
- PPP serial encapsulation
|
|
30
|
+
- IPSec transform-set lines
|
|
31
|
+
- site-to-site VPN crypto-map skeleton binding
|
|
27
32
|
|
|
28
33
|
## What This Does Not Prove
|
|
29
34
|
- It does not claim full synthetic VPN/IPSec/GRE/PPP configuration generation.
|
|
30
35
|
- It does not claim that every ASA/firewall or multilayer switch feature is editable.
|
|
36
|
+
- It does not claim ASA ACL/NAT, ASA service policy, CBAC, ZFW, or multilayer switching edit support.
|
|
31
37
|
- It does not allow `reference_only` donors as final apply donors.
|
|
32
38
|
- It does not change the `single-donor` final `.pkt` apply rule.
|
|
33
39
|
|
|
40
|
+
## Edit-Proven Commands
|
|
41
|
+
|
|
42
|
+
```text
|
|
43
|
+
set R1 gre tunnel Tunnel0 source 10.0.0.1 destination 10.0.0.2 ip 172.16.0.1/30
|
|
44
|
+
set R1 ppp interface Serial0/0/0 authentication chap
|
|
45
|
+
set R1 ipsec transform-set TS esp-aes esp-sha-hmac
|
|
46
|
+
set R1 crypto map VPNMAP 10 peer 203.0.113.2 transform-set TS match ACL_VPN interface Serial0/0/0
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
These commands are edit-proven only. They intentionally report
|
|
50
|
+
`generate_supported=false` and `generate_mismatch_reason=supported_in_edit_only`
|
|
51
|
+
until selected-donor acceptance evidence exists.
|
|
52
|
+
|
|
34
53
|
## Next Constrained Edit Candidates
|
|
35
|
-
- GRE tunnel parameter mutation on an existing routed donor.
|
|
36
|
-
- PPP/CHAP/PAP mutation on an existing serial or PPPoE donor.
|
|
37
|
-
- IPSec profile/key mutation on an existing site-to-site donor.
|
|
38
54
|
- ASA ACL/NAT mutation on an existing security-edge donor.
|
|
39
55
|
- SVI/routed-port mutation on an existing multilayer switch donor.
|
|
56
|
+
- CBAC/ZFW policy mutation on an existing routed security donor.
|
|
40
57
|
|
|
41
58
|
These candidates need separate roundtrip proof before they become release claims.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "packet-tracer-skill",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.3",
|
|
4
4
|
"private": false,
|
|
5
5
|
"description": "Donor-backed Cisco Packet Tracer 9.x skill for natural-language planning, safe-open generation, editing, parity reporting, and runtime diagnostics across coding hosts.",
|
|
6
6
|
"keywords": [
|
|
@@ -85,6 +85,14 @@
|
|
|
85
85
|
"docs/home-iot-donor-proof.md",
|
|
86
86
|
"docs/wan-security-donor-proof.md",
|
|
87
87
|
"docs/wireless-advanced-proof.md",
|
|
88
|
+
"docs/industrial-programming-proof.md",
|
|
89
|
+
"docs/automation-controller-proof.md",
|
|
90
|
+
"docs/voice-collaboration-proof.md",
|
|
91
|
+
"docs/l2-resiliency-bgp-proof.md",
|
|
92
|
+
"docs/ipv4-routing-management-proof.md",
|
|
93
|
+
"docs/l2-security-qos-proof.md",
|
|
94
|
+
"docs/security-edge-deepening-proof.md",
|
|
95
|
+
"docs/generate-ready-pilot-design.md",
|
|
88
96
|
"docs/packet-tracer-feature-gap-atlas.md",
|
|
89
97
|
"docs/discovery-keywords.md",
|
|
90
98
|
"docs/github-discussions-setup.md",
|
|
@@ -99,6 +107,7 @@
|
|
|
99
107
|
"docs/release-checklist.md",
|
|
100
108
|
"docs/release-notes-0.2.1.md",
|
|
101
109
|
"docs/release-notes-0.2.2.md",
|
|
110
|
+
"docs/release-notes-0.2.3.md",
|
|
102
111
|
"docs/runtime-truth.md"
|
|
103
112
|
],
|
|
104
113
|
"engines": {
|