packet-tracer-skill 0.2.0 → 0.2.2

package/CHANGELOG.md

@@ -2,9 +2,47 @@
 
 All notable changes to this project should be recorded in this file.
 
-The format is intentionally simple and release-oriented.
-
-## [0.2.0]
+The format is intentionally simple and release-oriented.
+
+## [0.2.2]
+
+### Added
+
+- advanced wireless proof surface for WEP and WPA Enterprise/RADIUS edit-proven behavior
+- wireless advanced feature atlas coverage for WLC, Meraki, cellular, Bluetooth, beamforming, guest Wi-Fi, WEP, and WPA Enterprise
+- runtime README guidance for generic Twofish bridge paths and search-root fallback
+
+### Changed
+
+- package version advanced to `0.2.2` for the README/runtime cleanup and advanced wireless feature wave
+- README runtime setup no longer presents a user-specific `.codex` path as the default bridge location
+- advanced wireless prompts now classify into the `wireless_advanced` family without drifting into `service_heavy`
+- WEP and WPA Enterprise/RADIUS are represented as edit-proven where explicit deterministic edit targets exist, while broader WLC/cellular/Bluetooth/Meraki scope remains report-only
+
+### Notes
+
+- `0.2.2` remains conservative: no broad synthetic advanced wireless generation is claimed
+- runtime messaging remains Windows-first and explicit about external bridge-assisted validation
+
+## [0.2.1]
+
+### Added
+
+- npm tarball hardening for the public package surface
+- launch announcement draft aligned with the current public release wording
+
+### Changed
+
+- package version advanced to `0.2.1` because `0.2.0` is already published on npm
+- npm package contents now exclude caches, generated previews, and non-essential screenshot payloads
+- public release references now consistently point to the `0.2.1` patch release artifacts
+
+### Notes
+
+- `0.2.1` is the publishable patch release for the conservative public preview surface
+- runtime messaging remains Windows-first and explicit about the external bridge-assisted validation path
+
+## [0.2.0]
 
 ### Added
 
@@ -14,7 +52,7 @@ The format is intentionally simple and release-oriented.
 - runtime truth, discovery keyword, GitHub metadata, publish-preview roadmap, and curated donor registry docs
 - seeded curated donor registry entries derived from known working public example artifacts
 - checked-in Packet Tracer template fallback assets for hermetic builder coverage
-- hero demo plan and `0.2.0` release notes draft artifacts for conservative launch prep
+- hero demo plan and `0.2.0` release notes draft artifacts for conservative launch prep
 
 ### Changed
 

package/README.md

@@ -8,21 +8,29 @@ Cisco Packet Tracer 9.x `.pkt` generator and editor for skill-based coding hosts
 
 This repository is built for one job: take a natural-language network request, build an explicit scenario-aware plan, adapt a compatible donor lab, and produce a Packet Tracer 9.x workflow that stays open-first and compatibility-first.
 
-`0.2.0` public preview prep is focused on:
+`0.2.2` public preview baseline is focused on:
 
 - donor-backed and scenario-aware public messaging
 - conservative Windows-first runtime truth
 - known working scenario set examples with acceptance-backed artifacts
-- release-notes-ready and GitHub-metadata-ready launch surface
+- README runtime cleanup, advanced wireless feature atlas coverage, and GitHub-launch-ops-ready metadata
 
-## Why It Is Different
-
-`packet-tracer-skill` is not a generic topology sketcher. It is a donor-backed Packet Tracer workflow with strict refusal behavior:
+## Why It Is Different
+
+`packet-tracer-skill` is not a generic topology sketcher. It is a donor-backed Packet Tracer workflow with strict refusal behavior:
 
 - generation stays `single-donor apply`
 - unsupported and acceptance-gated mutations do not fall back to guessed output
-- `--explain-plan`, `--compare-scenarios`, `--parity-report`, and `--doctor` are first-class product surfaces
-- curated donor evidence, fixture corpus checks, and runtime doctor output are part of the contract
+- `--explain-plan`, `--compare-scenarios`, `--parity-report`, and `--doctor` are first-class product surfaces
+- curated donor evidence, fixture corpus checks, and runtime doctor output are part of the contract
+
+In practice, that means the tool is trying to solve a narrower but more defensible problem than a prompt-to-diagram generator. It is designed to answer three questions in order:
+
+1. what the prompt is actually asking for
+2. whether the requested capability set is really supported for this scenario family
+3. whether a compatible donor and runtime path exist to carry the request safely
+
+If the answer to any of those is weak, the tool is expected to stop and explain why. That refusal behavior is part of the intended product quality, not a temporary limitation.
 
 Current product strengths:
 
@@ -32,7 +40,7 @@ Current product strengths:
 - runtime doctor contract with bridge resolution
 - known working examples with screenshots and acceptance excerpts
 
-## Runtime Reality
+## Runtime Reality
 
 Use the same repository, then install it into the skill path your host expects.
 
@@ -48,7 +56,14 @@ Use the same repository, then install it into the skill path your host expects.
 | OpenCode | `npx packet-tracer-skill --path .agents/skills` | `opencode run @pkt build a Packet Tracer lab with VLAN and DHCP` |
 | Custom path | `npx packet-tracer-skill --path ./my-skills` | depends on the host |
 
-The installer can be used on multiple hosts, but real `.pkt` runtime remains Windows-first and doctor-governed.
+The installer can be used on multiple hosts, but real `.pkt` runtime remains Windows-first and doctor-governed.
+
+That distinction matters because this project has two different surfaces:
+
+- installer or skill-copy success
+- actual Packet Tracer decode/edit/generate readiness
+
+The first one is relatively portable. The second one is not. README, npm text, release notes, and doctor output all need to preserve that difference or they become misleading.
 
 | Platform | Installer / skill copy | Real `.pkt` runtime |
 | --- | --- | --- |
@@ -56,12 +71,15 @@ The installer can be used on multiple hosts, but real `.pkt` runtime remains Win
 | macOS | Partially supported | Runtime contract defined, not acceptance-verified |
 | Linux | Partially supported | Runtime contract defined, not acceptance-verified |
 
-Important runtime rule:
+Important runtime rule:
 
-- installer success is not the same thing as runtime readiness
-- `--doctor` is the authority for whether real `.pkt` operations are ready
-- repo-local bridge and external bridge are reported separately
-- current strict validation is Windows-first and external-bridge-assisted
+- installer success is not the same thing as runtime readiness
+- `--doctor` is the authority for whether real `.pkt` operations are ready
+- repo-local bridge and external bridge are reported separately
+- current strict validation is Windows-first and external-bridge-assisted
+- `validate_open` can be ready while strict decode/edit/generate are still blocked
+
+The mixed case is especially important. If `validate_open` works, that only proves Packet Tracer can be launched. It does not prove the current checkout can decode or regenerate `.pkt` files safely. For strict work, donor availability and Twofish bridge resolution still decide the outcome.
 
 ## Quick Start
 
@@ -99,26 +117,36 @@ cd .\packet-tracer-skill
 powershell -ExecutionPolicy Bypass -File .\scripts\setup.ps1 -Dev
 ```
 
-Launch-prep references:
-
-- [docs/release-notes-0.2.0.md](docs/release-notes-0.2.0.md)
-- [docs/hero-demo-plan.md](docs/hero-demo-plan.md)
-- [docs/github-metadata.md](docs/github-metadata.md)
-- [docs/release-checklist.md](docs/release-checklist.md)
+Launch references:
+
+- [docs/release-notes-0.2.2.md](docs/release-notes-0.2.2.md)
+- [docs/hero-demo-plan.md](docs/hero-demo-plan.md)
+- [docs/github-metadata.md](docs/github-metadata.md)
+- [docs/release-checklist.md](docs/release-checklist.md)
+- [docs/github-launch-ops-0.2.2.md](docs/github-launch-ops-0.2.2.md)
+- [docs/campus-donor-proof.md](docs/campus-donor-proof.md)
+- [docs/home-iot-donor-proof.md](docs/home-iot-donor-proof.md)
+- [docs/wan-security-donor-proof.md](docs/wan-security-donor-proof.md)
+- [docs/wireless-advanced-proof.md](docs/wireless-advanced-proof.md)
+- [docs/packet-tracer-feature-gap-atlas.md](docs/packet-tracer-feature-gap-atlas.md)
 
 ## Runtime Doctor Contract
 
-`--doctor` is a product surface, not a debug afterthought. It reports:
-
-- `capability_impact`
-- `runtime_blockers`
-- `blocked_operations`
-- `ready_operations`
-- `recommended_next_steps`
-- `doctor_summary`
-- `runtime_grade`
-- `bridge_resolution`
-- `bridge_path_source`
+`--doctor` is a product surface, not a debug afterthought. It reports:
+
+- `capability_impact`
+- `runtime_blockers`
+- `blocked_operations`
+- `ready_operations`
+- `what_currently_works`
+- `what_is_blocked`
+- `why_it_is_blocked`
+- `best_next_fix`
+- `recommended_next_steps`
+- `doctor_summary`
+- `runtime_grade`
+- `bridge_resolution`
+- `bridge_path_source`
 - `bridge_recommendation`
 - `runtime_contract_notes`
 
@@ -134,25 +162,32 @@ Runtime grade states:
 - `partially_ready`
 - `blocked`
 
-Important distinction:
-
-- tests can pass with an external bridge override
-- that does not mean the repo is self-contained runtime-ready
-- the difference between repo-local readiness and external bridge fallback is part of the public contract
-
-Runtime truth reference:
-
-- [docs/runtime-truth.md](docs/runtime-truth.md)
+Important distinction:
+
+- tests can pass with an external bridge override
+- that does not mean the repo is self-contained runtime-ready
+- the difference between repo-local readiness and external bridge fallback is part of the public contract
+- mixed states should still read like a decision guide, not a debug dump
+
+Selector and runtime are intentionally kept separate:
+
+- donor selection can still block a prompt even when runtime is healthy
+- runtime can still block strict `.pkt` work even when a donor artifact exists
+- campus donor proof currently shows the first case more clearly than the second
+
+Runtime truth reference:
+
+- [docs/runtime-truth.md](docs/runtime-truth.md)
+- [docs/post-launch-follow-up.md](docs/post-launch-follow-up.md)
 
 ## Runtime Configuration
 
 Set the local Packet Tracer environment before real `.pkt` generation:
 
-```powershell
-$env:PACKET_TRACER_ROOT='C:\Program Files\Cisco Packet Tracer 9.0.0'
-$env:PACKET_TRACER_COMPAT_DONOR='C:\path\to\your-working-9.0-donor.pkt'
-$env:PKT_TWOFISH_LIBRARY="$env:USERPROFILE\.codex\skills\pkt\scripts\vendor\_twofish.cp314-win_amd64.pyd"
-```
+```powershell
+$env:PACKET_TRACER_ROOT='C:\Program Files\Cisco Packet Tracer 9.0.0'
+$env:PACKET_TRACER_COMPAT_DONOR='C:\path\to\your-working-9.0-donor.pkt'
+```
 
 Important variables:
 
@@ -161,14 +196,48 @@ Important variables:
 - `PACKET_TRACER_EXE`
 - `PACKET_TRACER_COMPAT_DONOR`
 - `PACKET_TRACER_TARGET_VERSION`
-- `PKT_TWOFISH_LIBRARY`
-- `PKT_TWOFISH_SEARCH_ROOTS`
-
-Required policy:
-
-- keep `PACKET_TRACER_TARGET_VERSION` on `9.0.0.0810`
-- do not downgrade the workflow to `5.3`
-- if donor or bridge is missing, fix the runtime instead of weakening the compatibility profile
+- `PKT_TWOFISH_LIBRARY`
+- `PKT_TWOFISH_SEARCH_ROOTS`
+
+Twofish bridge setup is intentionally local-machine specific. Do not copy another
+user's `.codex` path as if it were universal.
+
+Generic explicit bridge path:
+
+```powershell
+$env:PKT_TWOFISH_LIBRARY="C:\path\to\_twofish.cp314-win_amd64.pyd"
+```
+
+Repo-local bridge path, if you have placed a compatible bridge inside this
+checkout:
+
+```powershell
+$env:PKT_TWOFISH_LIBRARY="$PWD\scripts\vendor\_twofish.cp314-win_amd64.pyd"
+```
+
+Search-root fallback, if you want the runtime to look inside a local bridge
+folder:
+
+```powershell
+$env:PKT_TWOFISH_SEARCH_ROOTS="C:\path\to\bridge-folder"
+```
+
+Developer-local paths such as `$env:USERPROFILE\.codex\skills\...` are valid only
+for the person and host where that bridge exists. They are not the public setup
+contract.
+
+Required policy:
+
+- keep `PACKET_TRACER_TARGET_VERSION` on `9.0.0.0810`
+- do not downgrade the workflow to `5.3`
+- if donor or bridge is missing, fix the runtime instead of weakening the compatibility profile
+
+Troubleshooting guide:
+
+- `bridge_resolution=repo_local` means the checkout contains the bridge path the doctor resolved.
+- `bridge_resolution=external_env` means an environment variable points to a bridge outside the repo. This can be valid for testing, but it is not repo self-contained readiness.
+- `bridge_resolution=missing` means strict decode/edit/generate is blocked until `PKT_TWOFISH_LIBRARY` or `PKT_TWOFISH_SEARCH_ROOTS` resolves a compatible bridge.
+- `validate_open` readiness only proves Packet Tracer can launch a file. Strict `.pkt` generation still depends on donor and bridge readiness.
 
 ## Core Product Surfaces
 
@@ -184,37 +253,79 @@ Use `--compare-scenarios` when you need scenario comparison:
 python .\scripts\generate_pkt.py --compare-scenarios "campus with VLAN DHCP ACL" --compare-scenarios "smart home with IoT registration" --matrix-out .\output\compare.json
 ```
 
-Use `--parity-report` for prompt-scoped capability readiness:
+Use `--parity-report` for prompt-scoped capability readiness:
 
 ```powershell
-python .\scripts\generate_pkt.py --parity-report "service-heavy lab with DNS DHCP FTP email syslog AAA"
-```
-
-Stable CLI surfaces:
-
-- `--explain-plan`
-- `--compare-scenarios`
-- `--matrix-out`
-- `--coverage-report`
-- `--inventory-capabilities`
+python .\scripts\generate_pkt.py --parity-report "service-heavy lab with DNS DHCP FTP email syslog AAA"
+```
+
+Use `--feature-gap-report` for the Packet Tracer 9.0 feature atlas:
+
+```powershell
+python .\scripts\generate_pkt.py --feature-gap-report
+```
+
+The atlas now distinguishes report-only features from edit-proven features. IPv6/routing, a constrained L2 security/monitoring subset, and a narrow advanced-wireless edit subset can be edited with explicit commands, but none of these are claimed as broad generate-ready without donor-backed acceptance evidence.
+
+Current feature-support truth:
+
+| Area | Current status | Safe action |
+| --- | --- | --- |
+| Campus / service-heavy / Home IoT / WAN-security scenario families | Donor-aware planning and parity/report surfaces | Use `--explain-plan`, `--compare-scenarios`, and donor proof docs before strict generate claims |
+| IPv6/routing | Edit-proven subset | Use explicit router/interface commands; strict generate still needs selected-donor acceptance |
+| L2 security/monitoring | Edit-proven subset | Use explicit DHCP snooping, DAI, LLDP, REP, SNMP, NetFlow, SPAN/RSPAN, and port-security commands |
+| Advanced wireless | WEP and WPA Enterprise/RADIUS are explicit-edit capable; WLC, Meraki, cellular, Bluetooth, beamforming, and guest Wi-Fi remain report-only | Keep controller/cellular/Bluetooth claims in atlas/report mode until donor-backed proof exists |
+| Voice, automation/controller, industrial IoT, physical/media gaps | Report-supported atlas entries | Do not claim edit/generate support until a proof wave promotes them |
+
+The important number is still `generate_ready=0` for the atlas gap families. That is deliberate: visibility comes first, then edit proof, then donor-backed readiness, and only then generate readiness.
+
+Stable CLI surfaces:
+
+- `--explain-plan`
+- `--compare-scenarios`
+- `--matrix-out`
+- `--coverage-report`
+- `--feature-gap-report`
+- `--inventory-capabilities`
 - `--doctor`
 - `--parity-report`
 - `--acceptance-json-out`
 
 ## Curated Donor and Fixture Truth Sources
 
-This repository keeps explicit truth sources for donor evidence and scenario regression:
-
-- `references/curated-donor-registry.json`
-- `references/scenario-fixture-corpus.json`
-
-Curated donor registry reference:
-
-- [docs/curated-donor-registry.md](docs/curated-donor-registry.md)
-
-## Known Working Scenario Set
-
-Public examples stay text-first and review-friendly. Raw `.pkt` binaries are not committed.
+This repository keeps explicit truth sources for donor evidence and scenario regression:
+
+- `references/curated-donor-registry.json`
+- `references/scenario-fixture-corpus.json`
+- `references/packettracer-feature-atlas.json`
+
+Curated donor registry reference:
+
+- [docs/curated-donor-registry.md](docs/curated-donor-registry.md)
+
+Current selector truth:
+
+- a registry-backed donor can be inventory-proof without being prompt-selected
+- selector output should explain the closest rejected donor class when generate is blocked
+- `best_rejected_donor_class` and `primary_rejection_code` are intended to keep donor-limited refusals specific
+- Home IoT readiness is only raised when the selected donor and prompt targets are both deterministic
+- WAN/security readiness is only raised for explicit WAN/security intent when the selected donor carries matching WAN, security, tunnel, or multilayer runtime evidence
+- Feature atlas entries are report-first; a feature can be visible in the atlas while still blocked for edit/generate.
+
+## Known Working Scenario Set
+
+Public examples stay text-first and review-friendly. Raw `.pkt` binaries are not committed.
+
+These examples are not decorative screenshots. They are the public proof set for the current product contract. Each one is intended to show a scenario family that was actually exercised through donor-backed logic and then reduced into reviewable artifacts:
+
+- screenshot
+- inventory manifest
+- acceptance excerpt
+- parity excerpt
+- decision excerpt
+- runtime excerpt
+
+This is why the examples surface matters so much in release work. It is the shortest path from a marketing claim to a falsifiable engineering artifact.
 
 Canonical public examples:
 
@@ -234,11 +345,38 @@ Primary screenshot:
 
 ![Packet Tracer topology](examples/screenshots/complex_campus_master_edit_v4.png)
 
-Hero visual for the `0.2.0` launch-prep surface:
+Hero visual for the `0.2.2` public preview surface:
 
 - `examples/screenshots/complex_campus_master_edit_v4.png`
 
-The gallery is treated as a known working scenario set, not just a screenshot list, and the same canonical set feeds release notes and GitHub metadata.
+The gallery is treated as a known working scenario set, not just a screenshot list, and the same canonical set feeds release notes and GitHub metadata.
+
+Canonical public proof:
+
+- [docs/campus-donor-proof.md](docs/campus-donor-proof.md)
+- [docs/home-iot-donor-proof.md](docs/home-iot-donor-proof.md)
+- [docs/wan-security-donor-proof.md](docs/wan-security-donor-proof.md)
+
+The campus donor proof is intentionally more specific than the gallery cards. It shows that a real donor artifact inventories correctly, but it also shows that a generalized campus prompt can still be donor-limited. That is exactly the kind of nuance the public docs should preserve.
+
+The Home IoT donor proof is intentionally narrower than a generic smart-home claim. It shows that donor-backed registration, rule control, and wireless association are integrated only inside a constrained path with explicit targets and a selected donor.
+
+The WAN/security donor proof is also conservative. It shows family-correct report/selection behavior and donor-backed readiness semantics for VPN, IPSec, GRE, PPP, security-edge, and multilayer evidence, but it does not claim broad synthetic WAN/security configuration generation.
+
+The advanced wireless proof is narrower again. It promotes only explicit WEP and WPA Enterprise/RADIUS edit semantics while keeping WLC, Meraki, cellular, Bluetooth, beamforming, and guest Wi-Fi in report-only atlas mode.
+
+What the proof now tries to surface explicitly:
+
+- a real donor exists
+- inventory succeeds
+- the larger generalized prompt is still refused
+- the blocking layer is donor selection, not runtime
+- the closest rejected donor class and rejection code should be visible in the decision payload
+
+Classifier truth matters here too:
+
+- shorthand campus prompts should still resolve to the `campus` family
+- donor-limited campus refusal should be read as a campus selector result, not a service-heavy misclassification
 
 ## Security and Privacy
 
@@ -263,9 +401,18 @@ See also:
 - [docs/release-checklist.md](docs/release-checklist.md)
 - [docs/github-discussions-setup.md](docs/github-discussions-setup.md)
 
-## Release Readiness
-
-This repo is being hardened toward a publish-ready and release-ready surface.
+## Release and Launch State
+
+The npm package release target for this batch is `packet-tracer-skill@0.2.2`. Remaining launch ops are GitHub release application, About/Topics updates, Discussions setup, and public proof follow-up.
+
+So the current state is no longer “preparing to publish.” The package line is public. The remaining work is about making the public surface honest and complete:
+
+- GitHub release object should match the published npm state
+- About/Topics should match the README and launch wording
+- Discussions should exist as the feedback intake surface
+- donor proof should exist as the first post-launch technical evidence layer
+
+That is the difference between “published” and “productized.” The current repo is published; these follow-up documents are what make it operationally coherent.
 
 Recommended local validation before release:
 
@@ -277,12 +424,14 @@ python .\scripts\generate_pkt.py --parity-report "campus with VLAN DHCP ACL"
 python .\scripts\runtime_doctor.py
 ```
 
-Publish-preview references:
-
-- [docs/release-checklist.md](docs/release-checklist.md)
-- [docs/publish-preview-roadmap.md](docs/publish-preview-roadmap.md)
-- [docs/discovery-keywords.md](docs/discovery-keywords.md)
-- [docs/github-metadata.md](docs/github-metadata.md)
+Launch ops references:
+
+- [docs/release-checklist.md](docs/release-checklist.md)
+- [docs/publish-preview-roadmap.md](docs/publish-preview-roadmap.md)
+- [docs/discovery-keywords.md](docs/discovery-keywords.md)
+- [docs/github-metadata.md](docs/github-metadata.md)
+- [docs/github-launch-ops-0.2.2.md](docs/github-launch-ops-0.2.2.md)
+- [docs/post-launch-follow-up.md](docs/post-launch-follow-up.md)
 
 ## Azerbaijani Summary
 
@@ -298,7 +447,7 @@ Bu repo təbii dil ilə Packet Tracer `.pkt` generate və edit etmək üçündü
 
 Hazırkı prioritet:
 
-- `0.2.0` public preview prep
+- `0.2.2` public preview hardening
 - release-ready və publish-ready surface
 - README / npm / GitHub discoverability hizalanması
 - scenario truth source, donor registry və runtime doctor contract consistency

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
@@ -49,3 +68,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/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