packet-tracer-skill 0.2.3 → 0.3.0

package/bin/packet-tracer-skill.js

@@ -1036,12 +1036,39 @@ function main() {
         }
       }
       printEnvExamples(runtimeDoctor);
-      const failed = checks.some(([, ok]) => !ok);
+      // The verdict follows the checks that decide whether anything is
+      // actually blocked, not "did any line print MISSING". A fresh install
+      // reported `RUNTIME_GRADE ready`, `BLOCKED_OPERATIONS none` and every
+      // capability ready, and then closed with "Runtime is not fully ready"
+      // and exit 1 -- because `TWOFISH_SHA256` is a checksum of the optional
+      // compiled bridge, which is absent by design when the vendored
+      // pure-Python engine is in use. A first-time user reads that as a failed
+      // install.
+      const status = checkMap(checks);
+      const isClear = (name) => {
+        const entry = status.get(name);
+        if (!entry) return true;
+        const detail = (entry.detail || "").trim().toLowerCase();
+        return entry.ok || detail === "" || detail === "none";
+      };
+      const gradeEntry = status.get("RUNTIME_GRADE");
+      const grade = (gradeEntry && gradeEntry.detail ? gradeEntry.detail : "").trim();
+      const failed =
+        (grade !== "" && grade !== "ready") ||
+        !isClear("RUNTIME_BLOCKERS") ||
+        !isClear("BLOCKED_OPERATIONS");
       if (failed) {
         console.error("\nRuntime is not fully ready. Install copies are fine, but Packet Tracer generation still needs the missing items above.");
         process.exit(1);
       }
-      console.log("\nRuntime looks ready.");
+      const informational = checks.filter(([, ok]) => !ok).map(([name]) => name);
+      if (informational.length > 0) {
+        console.log(
+          `\nRuntime looks ready. Optional items not present: ${informational.join(", ")}.`
+        );
+      } else {
+        console.log("\nRuntime looks ready.");
+      }
       process.exit(0);
     }
 

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

@@ -0,0 +1,37 @@
+# GitHub Launch Ops for `v0.2.3`
+
+`packet-tracer-skill@0.2.3` is the current published capability release. This runbook is the active launch-ops source for the published line.
+
+## Release Object
+
+1. Ensure tag `v0.2.3` points to the publish commit.
+2. Create or verify the GitHub Release title `v0.2.3`.
+3. Use `docs/release-notes-0.2.3.md` as the release body source.
+4. Keep the hero visual as `examples/screenshots/complex_campus_master_edit_v4.png`.
+
+## About And Topics
+
+Use `docs/github-metadata.md` as the current source of truth.
+
+The public wording should say:
+
+- donor-backed
+- open-first
+- scenario-aware
+- Windows-first runtime
+- validated with external bridge override
+
+Do not claim repo-local self-contained runtime readiness unless `runtime_doctor` semantics change.
+
+## Discussions
+
+Recommended categories:
+
+- `Showcase`
+- `Q&A`
+- `Donor Requests`
+- `Capability Roadmap`
+
+## Next Candidate
+
+`0.2.4` is a candidate product-hardening patch for Examples Truth 2.0, proof-card discoverability, local sample evidence, and proof-readiness promotion planning. It should not be presented as published until version, tag, npm, and release notes are finalized.

package/docs/github-metadata.md

@@ -27,13 +27,15 @@ Pinned screenshot:
 
 Pinned caption:
 
-- `donor-backed complex campus proof artifact for the 0.2.2 public preview`
+- `donor-backed complex campus proof artifact for the 0.2.3 capability release`
 
 ## 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`
+- current published release title: `v0.2.3`
+- current release body source: `docs/release-notes-0.2.3.md`
+- current launch ops source: `docs/github-launch-ops-0.2.3.md`
+- next candidate release notes draft: `docs/release-notes-0.2.4.md`
+- historical `0.2.2` launch wording remains archived in `docs/launch-announcement-0.2.2.md`
 
 ## Discussions Categories
 

package/docs/hero-demo-plan.md

@@ -2,7 +2,7 @@
 
 ## Goal
 
-Prepare one conservative hero demo flow for the `0.2.1` public preview surface without implying self-contained runtime readiness.
+Prepare one conservative hero demo flow for the current `0.2.3` capability release and the next `0.2.4` candidate surface without implying self-contained runtime readiness.
 
 ## Prompt
 

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

@@ -25,15 +25,15 @@ Observed Home IoT proof facts:
   - IoT rule enable/disable state
   - donor-backed wireless association
 
-## Donor-Backed Generate Interpretation
+## Donor-Backed Readiness 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
+- `iot_registration`, `iot_control`, and `wireless_client_association` are only considered donor-backed 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`.
+This is why the public wording uses `donor-backed constrained edit/readiness` rather than broad smart-home generation.
 
 ## What This Proves
 
@@ -45,7 +45,7 @@ This is why the public wording uses `donor-backed constrained-generate` rather t
 ## 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 prove every prompt mentioning IoT registration is donor-backed ready or generation 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
 

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

@@ -1,6 +1,6 @@
 # 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.
+This proof records the published `0.2.3` L2 security/QoS edit-proven subset and the `0.2.4` candidate proof-readiness context. 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
 

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

@@ -10,7 +10,7 @@ It is intentionally conservative:
 - `donor_backed_ready` requires selected-donor evidence or a validated proof-linked explicit edit gate with sample, decode, and roundtrip evidence.
 - `generate_ready` requires acceptance-backed generate behavior.
 
-The atlas does not claim that every Packet Tracer feature is generate-ready. It turns missing or under-modelled Packet Tracer features into an auditable backlog before any broad config mutation is opened.
+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.
 
 ## Remote Sample Evidence
 
@@ -39,7 +39,7 @@ IPv6 tunneling, ISATAP, prefix delegation, and AAAA DNS remain report-first unti
 
 ## Second Edit-Proven Wave
 
-The second promotion wave is `l2_security_monitoring`. The following subset is edit-proven for explicit commands, but still not broad generate-ready:
+The second promotion wave is `l2_security_monitoring`. The following subset is edit-proven for explicit commands, but still not broad `generate_ready`:
 
 - DHCP snooping
 - Dynamic ARP Inspection
@@ -210,8 +210,8 @@ is evidence input, not a public curated donor registry.
 ## Current Feature Families
 
 - `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.
-- `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.
-- `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.
+- `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`.
+- `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`.
 - `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.
 - `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.
 - `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.

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

@@ -2,10 +2,13 @@
 
 ## Immediate Follow-Up Items
 
-- complete GitHub launch ops from `docs/github-launch-ops-0.2.2.md`
-- publish one canonical donor proof artifact: `docs/campus-donor-proof.md`
-- publish one Home IoT donor proof artifact: `docs/home-iot-donor-proof.md`
-- publish one WAN/security donor proof artifact: `docs/wan-security-donor-proof.md`
+- keep the published `0.2.3` surface aligned across README, npm, changelog, release notes, proof docs, and examples
+- freeze the `Examples Truth 2.0` proof-card/gallery surface as the first `0.2.4` candidate batch
+- use `docs/proof-readiness-dashboard.md` and `references/proof-readiness-candidates.json` as the next engineering queue
+- keep canonical proof artifacts discoverable from README and examples:
+  - `docs/campus-donor-proof.md`
+  - `docs/home-iot-donor-proof.md`
+  - `docs/wan-security-donor-proof.md`
 - keep README, release notes, launch announcement, and GitHub metadata in sync
 
 ## Next Technical Proof Batch
@@ -24,13 +27,14 @@
 - treat runtime clarity as a product surface, not a debug detail
 - keep `what_currently_works`, `what_is_blocked`, and `best_next_fix` aligned with `doctor_summary`
 
-## Trigger Conditions for `0.2.2` or the Next Minor
+## Trigger Conditions for `0.2.4`
 
 - README / npm / GitHub wording drift
 - donor proof uncovers a concrete selector mismatch worth productizing
 - runtime doctor wording becomes ambiguous again
 - examples and public proof artifacts stop matching current behavior
 - selected donor refusal becomes too generic to explain the closest rejected donor class
+- proof-readiness candidates gain enough selected-donor evidence to justify promotion
 
 ## Next Integration Wave
 

package/docs/proof-readiness-dashboard.md

@@ -0,0 +1,69 @@
+# Proof Readiness Dashboard
+
+This dashboard is the `0.2.4` candidate planning surface for moving features from `edit_proven` toward `donor_backed_ready`.
+
+It combines three sources:
+
+- proof cards in `examples/proof-cards.json`
+- feature support ceilings in `references/packettracer-feature-atlas.json`
+- local sample evidence summarized in `examples/local-sample-evidence.json`
+
+It does not enable broad generation. The current product truth remains `generate_ready=0`.
+
+## Status Contract
+
+- `report_supported`: the feature is recognized and can be reported, but no edit claim is made.
+- `edit_proven`: explicit command or script-file roundtrip has evidence.
+- `donor_backed_ready`: selected donor or proof-linked explicit edit path is safe for a narrow prompt-scoped workflow.
+- `blocked_by_missing_decode_evidence`: sample-path evidence exists, but decode-backed evidence is not sufficient.
+- `blocked_by_missing_roundtrip`: inventory or parser truth exists, but editor roundtrip proof is missing.
+- `blocked_by_no_deterministic_target`: edit proof exists, but selected donor / device / interface / object resolution is not yet locked.
+
+## Primary Queue
+
+Primary candidates are the highest-value next promotion targets because local evidence is strong and the edit surface is IOS text only:
+
+- `ospfv2`
+- `eigrp_ipv4`
+- `ripv2`
+- `static_route`
+- `default_route`
+- `dhcp_relay`
+- `ssh_ios`
+- `ntp_ios`
+- `syslog_ios`
+
+These remain `edit_proven` until selected-donor evidence and deterministic target resolution are proof-linked. Broad routing, NAT, and management design generation stays blocked.
+
+## Secondary Queue
+
+Secondary candidates are L2 resiliency and BGP features with strong local sample evidence but more topology-sensitive safety requirements:
+
+- `stp`
+- `rstp`
+- `etherchannel`
+- `lacp`
+- `pagp`
+- `vtp`
+- `dtp`
+- `bgp`
+
+These features should not inherit donor readiness from generic sample counts. Promotion requires explicit command shape, decode-backed sample evidence, editor roundtrip, deterministic target resolution, and clean refusal on ambiguous targets.
+
+## Promotion Rule
+
+A candidate can be promoted only when all of these are true:
+
+- an explicit command shape exists
+- parser and parity recognize the capability without family drift
+- sample evidence exists
+- decode evidence exists
+- editor roundtrip test exists
+- device/interface/object targets are deterministic
+- ambiguity produces a clean refusal
+
+If any item is missing, the feature stays `edit_proven` or `report_supported`.
+
+## Next Safe Action
+
+Use `references/proof-readiness-candidates.json` as the implementation queue. Do not add new random capability names until the primary queue either promotes or records a concrete blocker.

package/docs/publish-preview-roadmap.md

@@ -11,16 +11,17 @@
 
 ## Step B: Public `0.2.x` Publish-Preview
 
-- `package.json` is versioned at `0.2.2`
-- npm publish target is `packet-tracer-skill@0.2.2`
-- release notes source is ready: `docs/release-notes-0.2.2.md`
+- `packet-tracer-skill@0.2.3` is the current published capability release
+- next candidate line is `0.2.4`, with notes drafted in `docs/release-notes-0.2.4.md`
+- package version remains `0.2.3` until a `0.2.4` publish decision is made
 - hero visual is locked to `examples/screenshots/complex_campus_master_edit_v4.png`
 - hero demo execution plan is ready: `docs/hero-demo-plan.md`
 - GitHub About/Topics text is finalized in `docs/github-metadata.md`
-- launch ops runbook is ready: `docs/github-launch-ops-0.2.2.md`
+- active launch ops source is `docs/github-launch-ops-0.2.3.md`
+- historical `0.2.1` and `0.2.2` launch ops runbooks remain archived
 - npm publish checklist is complete and conservative runtime wording is preserved
 - remaining public launch ops are:
-  - GitHub release creation
+  - GitHub release object verification for the current published tag
   - About/Topics update in GitHub UI
   - Discussions opening
   - release announcement application

package/docs/release-checklist.md

@@ -1,6 +1,6 @@
 # Release Checklist
 
-Target release surface: `0.2.3` capability proof/readiness release.
+Target release surface: `0.2.4` candidate product-hardening patch on top of the published `0.2.3` capability release.
 
 ## Product Contract
 
@@ -17,10 +17,16 @@ python .\scripts\build_examples_index.py
 python -m pytest tests -q
 node --check .\bin\packet-tracer-skill.js
 python .\scripts\generate_pkt.py --parity-report "campus with VLAN DHCP ACL"
-python .\scripts\runtime_doctor.py
-```
-
-## Package Audit
+python .\scripts\runtime_doctor.py
+```
+
+Runtime profile:
+
+- default `python -m pytest tests -q` may skip `requires_twofish` tests when no local bridge is resolved
+- strict release runtime gate must set `PKT_REQUIRE_TWOFISH_TESTS=1` and resolve `PKT_TWOFISH_LIBRARY` or `PKT_TWOFISH_SEARCH_ROOTS`
+- `PKT_REQUIRE_TWOFISH_TESTS=1 python -m pytest tests -q` must pass before publishing any release that claims strict `.pkt` runtime proof
+
+## Package Audit
 
 - `package.json` description matches current product scope
 - keyword clusters cover Packet Tracer, networking labs, AI/natural language, and host ecosystems
@@ -36,10 +42,13 @@ python .\scripts\runtime_doctor.py
 - local `pkt_examples` files remain local evidence only; no raw `.pkt`, `.pka`, local audit cache, or user-supplied corpus files are packaged
 - examples index and gallery were rebuilt
 - screenshots are intentional and non-sensitive
-- changelog entry is updated for `0.2.3`
-- release notes source exists: `docs/release-notes-0.2.3.md`
+- changelog entry is updated for the candidate release
+- release notes source exists: `docs/release-notes-0.2.4.md`
+- proof-readiness dashboard exists: `docs/proof-readiness-dashboard.md`
+- proof-readiness candidates exist: `references/proof-readiness-candidates.json`
 - hero demo plan exists: `docs/hero-demo-plan.md`
-- GitHub launch ops runbook exists: `docs/github-launch-ops-0.2.2.md`
+- current GitHub launch ops runbook exists: `docs/github-launch-ops-0.2.3.md`
+- historical GitHub launch ops runbooks remain archived and current metadata points at the published release
 - canonical donor proof exists: `docs/campus-donor-proof.md`
 - hero visual is selected: `examples/screenshots/complex_campus_master_edit_v4.png`
 - runtime truth docs match current `runtime_grade` and `bridge_resolution` semantics

package/docs/release-notes-0.2.4.md

@@ -0,0 +1,20 @@
+# `packet-tracer-skill` `0.2.4` Release Notes Draft
+
+`0.2.4` is planned as a product hardening patch for the post-`0.2.3` capability surface.
+
+The intended focus is examples truth, proof-card discoverability, local sample evidence presentation, and a proof-readiness promotion queue. It is not a broad generate-ready release.
+
+## Planned Highlights
+
+- Examples Truth 2.0 model with `showcase_example` and `proof_card` artifacts.
+- Local sample evidence board summarized without committing raw `.pkt/.pka` files.
+- Proof-readiness dashboard for the next donor-backed promotion wave.
+- Promotion queue for IPv4 routing/management and L2 resiliency/BGP candidates.
+- Guided user summaries for doctor, parity, and explain-plan workflows.
+- Current docs wording aligned around `0.2.3` as the published release and `0.2.4` as the next candidate.
+
+## Safety Posture
+
+- `generate_ready=0` remains intentional.
+- Raw `.pkt/.pka`, `pkt_examples`, and `output/` artifacts stay out of git and npm.
+- Proof cards and promotion queues are planning and evidence surfaces, not broad topology generation claims.

package/docs/runtime-truth.md

@@ -47,14 +47,39 @@ Another mixed case:
 - that still means the checkout is only partially ready as a packaged repo surface
 - docs should continue saying `validated with external bridge override` rather than implying repo-local readiness
 
-## Bridge Resolution
-
-- `repo_local`
-  A repo-local vendor bridge is resolved.
-- `external_env`
-  A bridge is only available through an external environment path.
-- `missing`
-  No usable bridge is resolved.
+## Twofish Engine
+
+The cipher is no longer a runtime blocker. `scripts/vendor/twofish_pure.py` is a
+vendored pure-Python Twofish, verified against the official test vectors at
+diagnostic time, so `decode`, `inventory`, `edit`, and `generate` are available
+on a clean checkout with no binaries and no environment variables.
+
+`twofish_backend` reports which engine is active:
+
+- `pure_python`
+  The vendored repo-local engine. Always available. This is the baseline.
+- `compiled`
+  A `_twofish` C bridge resolved from `PKT_TWOFISH_LIBRARY`,
+  `PKT_TWOFISH_SEARCH_ROOTS`, or `scripts/vendor/`. Optional, roughly 12x faster
+  on large labs, and bit-identical to the pure engine.
+
+`bridge_resolution` describes only where the *optional accelerator* came from.
+It no longer downgrades `runtime_grade`, and `external_env` is not a blocker.
+
+## Test Profiles
+
+There is one gate. The suite runs the same way with or without a compiled
+bridge, and nothing is skipped for lack of one:
+
+```
+python -m pytest tests -q
+```
+
+`PKT_REQUIRE_TWOFISH_TESTS=1` is still honoured for hosts that want to assert a
+compiled accelerator is present, but it is no longer needed to prove real
+`.pkt` decode/edit works.
+
+The doctor payload exposes this as `runtime_gate_status` and repeats the most useful user-facing answer in `user_summary`. Consumers should show `user_summary.status`, `user_summary.message`, and `user_summary.next_best_action` before dumping the full diagnostic JSON.
 
 ## Publish-Preview Policy
 

package/docs/security-edge-deepening-proof.md

@@ -1,6 +1,6 @@
 # Security Edge Deepening Proof
 
-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.
+This proof records the published `0.2.3` router-based security edge edit-proven subset and the `0.2.4` candidate proof-readiness context. 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.
 
 ## Explicit Commands
 

package/examples/README.md

@@ -1,75 +1,104 @@
-## Known Working Scenario Set
-
-This repo keeps text-based example artifacts under `examples/` and treats them as a known working scenario set, not just a screenshot folder.
-
-For the `0.2.1` public preview surface, the canonical public set is:
-
-- `complex_campus_master_edit_v4`
-- `home_iot_cli_edit_v1`
-- `service_heavy_cli_edit_v1`
-
-Hero visual:
-
-- `screenshots/complex_campus_master_edit_v4.png`
-
-Policy:
-- generated `.pkt` and `.xml` files stay gitignored
-- public examples should be sanitized JSON or markdown summaries
-- if you want to publish a lab sample, prefer `--inventory --inventory-out` and commit the resulting JSON
-- real Packet Tracer screenshots can be committed under `examples/screenshots/`
-- examples may have one primary screenshot plus additional detail screenshots
-
-Example command:
-
-```powershell
-python .\scripts\generate_pkt.py --inventory .\output\complex_campus_master_edit_v4.pkt --inventory-capabilities --inventory-out .\examples\complex_campus_master_edit_v4.inventory.json
-```
-
-Current curated example:
-- `complex_campus_master_edit_v4.inventory.json`
-  Donor-backed complex campus edit showing management VLAN, Telnet, ACL, server services, and wireless updates without publishing the binary `.pkt` itself.
-- `screenshots/complex_campus_master_edit_v4.png`
-  Visual snapshot of the same lab opened inside Cisco Packet Tracer.
-
-Additional curated examples:
-- `home_iot_cli_edit_v1.inventory.json`
+## Examples Truth 2.0
+
+The `examples/` directory is the public proof surface for the published `0.2.3` capability release and the next `0.2.4` candidate hardening batch. It is not a raw Packet Tracer lab dump and it is not a claim that broad `.pkt` generation is solved.
+
+Global truth:
+
+- atlas `generate_ready=0` remains intentional
+- raw `.pkt` and `.pka` files stay out of git and npm
+- local `pkt_examples` audits are evidence inputs only
+- examples are either `showcase_example` artifacts or text-only `proof_card` artifacts
+
+## Artifact Types
+
+`showcase_example` means:
+
+- there is a screenshot and committed inventory manifest
+- the source workflow is donor-backed or acceptance-backed as an example artifact
+- the binary `.pkt` is not committed
+- the example can be used in README/npm/GitHub proof surfaces
+
+`proof_card` means:
+
+- there is no raw `.pkt` and no screenshot requirement
+- the card points to a proof doc
+- it records the explicit command shape, scenario family, support level, parity excerpt, and refusal boundary
+- it proves a narrow edit/readiness path, not broad topology generation
+
+## Current Showcase Examples
+
+- `complex_campus_master_edit_v4`
+  Donor-backed complex campus edit showing management VLAN, Telnet, ACL, server services, and wireless updates without publishing the binary `.pkt`.
+  Screenshot: `screenshots/complex_campus_master_edit_v4.png`.
+- `home_iot_cli_edit_v1`
   Home gateway and IoT registration example focused on donor-backed, constrained gateway device onboarding.
-- `screenshots/home_iot_cli_edit_v1.png`
-  Topology snapshot for the Home IoT example.
-- `service_heavy_cli_edit_v1.inventory.json`
-  Service-heavy server example focused on DNS, DHCP, FTP, email, syslog, AAA, and related service metadata.
-- `screenshots/service_heavy_cli_edit_v1.png`
-  Topology snapshot for the Service Heavy example.
-- `screenshots/service_heavy_cli_edit_v1_*.png`
-  Additional service detail screenshots for DHCP, DNS, and FTP views.
-- `index.json`
-  Lightweight gallery index for curated example artifacts.
-
-Rebuild the gallery index:
-
-```powershell
-python .\scripts\build_examples_index.py
-```
-
-Generated outputs:
-- `index.json`
-  Machine-readable curated example index.
-- `gallery.md`
-  Human-readable markdown gallery generated from the same source, positioned as the known working scenario set.
-- `previews/*.svg`
-  Generated fallback preview images for examples that do not yet have real Packet Tracer screenshots.
-
-Gallery families:
-- `campus`
-  VLAN, management, ACL, server services, and wireless edits.
-- `home_iot`
-  Home gateway, IoT things, registration, and constrained donor-backed wireless examples.
-- `service_heavy`
-  Server-centric service labs with richer metadata.
-
+  Screenshot: `screenshots/home_iot_cli_edit_v1.png`.
+- `service_heavy_cli_edit_v1`
+  Service-heavy server example focused on DNS, DHCP, FTP, email, syslog, AAA, and related service metadata.
+  Screenshot: `screenshots/service_heavy_cli_edit_v1.png`.
+
+## Current Proof Cards
+
+The proof cards make the `0.2.3` capability waves discoverable from the examples gallery and feed the `0.2.4` proof-readiness dashboard:
+
+- IPv4 routing / NAT / IOS management
+- L2 resiliency + BGP
+- L2 security + QoS
+- security-edge CBAC/ZFW
+- voice/collaboration
+- automation/controller
+- industrial programming
+
+The source file is `proof-cards.json`. It is text-only and diff-friendly.
+
+## Proof-Readiness Queue
+
+The `0.2.4` candidate adds a promotion queue for deciding which edit-proven features can safely move toward `donor_backed_ready`.
+
+- source artifact: `..\references\proof-readiness-candidates.json`
+- dashboard: `..\docs\proof-readiness-dashboard.md`
+- current primary queue: IPv4 routing, NAT, DHCP relay, SSH, NTP, and syslog IOS management
+- current secondary queue: STP/RSTP, EtherChannel/LACP/PAgP, VTP/DTP, and BGP
+
+The queue is intentionally conservative. Local sample counts are not enough by themselves; each promotion still needs explicit command shape, decode evidence, editor roundtrip, deterministic target resolution, and clean refusal behavior.
+
+## Local Sample Evidence
+
+The local audit command can summarize user-supplied Packet Tracer labs:
+
+```powershell
+python .\scripts\generate_pkt.py --local-sample-audit-root "C:\path\to\pkt_examples"
+```
+
+The default output is `output/local-sample-audit.json`. That file is ignored by git and npm packaging. It can show evidence such as STP, static routes, RIPv2, OSPFv2, DHCP, ACL, SSH, NAT, HSRP, EtherChannel, and BGP counts, but it does not promote those local files into curated public donors.
+
+## Rebuild
+
+Rebuild the generated index and gallery:
+
+```powershell
+python .\scripts\build_examples_index.py
+```
+
+Generated outputs:
+
+- `index.json`: machine-readable combined showcase/proof-card index
+- `gallery.md`: human-readable examples and evidence gallery
+- `previews/*.svg`: generated fallback preview images for showcase examples without screenshots
+
 Launch references:
+
 - `..\docs\hero-demo-plan.md`
-- `..\docs\release-notes-0.2.1.md`
+- `..\docs\release-notes-0.2.3.md`
+- `..\docs\release-notes-0.2.4.md`
+- `..\docs\proof-readiness-dashboard.md`
 - `..\docs\campus-donor-proof.md`
 - `..\docs\home-iot-donor-proof.md`
 - `..\docs\wan-security-donor-proof.md`
+- `..\docs\ipv4-routing-management-proof.md`
+- `..\docs\l2-resiliency-bgp-proof.md`
+- `..\docs\l2-security-qos-proof.md`
+- `..\docs\security-edge-deepening-proof.md`
+- `..\docs\voice-collaboration-proof.md`
+- `..\docs\automation-controller-proof.md`
+- `..\docs\industrial-programming-proof.md`

package/examples/complex_campus_master_edit_v4.inventory.json

@@ -1,10 +1,20 @@
 {
+  "schema_version": "examples.truth.v2",
   "example_name": "complex_campus_master_edit_v4",
+  "artifact_type": "showcase_example",
   "source_mode": "donor-backed edit",
   "scenario_family": "campus",
-  "public_repo_policy": {
+  "artifact_policy": {
     "commit_pkt_binary": false,
-    "commit_inventory_json": true
+    "commit_inventory_json": true,
+    "commit_screenshots": true,
+    "raw_source_public": false
+  },
+  "maturity_summary": {
+    "atlas_status": "known_working_example",
+    "example_status": "known_working_example",
+    "donor_backed_ready": true,
+    "generate_ready": false
   },
   "artifact_paths": {
     "screenshot": "examples/screenshots/complex_campus_master_edit_v4.png",