Jesse A. GreenAI lab portfolio

pausedPrototype, mock-tested only. Paused until a real test bed is available.

Panorama fleet dashboard (panoview)

One read-only view across many Panoramas: a mind map of the fleet, an Attention list, search and exports. Built for my role; shown here with mock data only. Prototype, mock-tested only.

Open appAll projectspanoview.doccompiler.ai
AI's role
Plan, code milestone by milestone, review-fix pass, screenshot review
My role
Constraints, two safety switches; owns the real-environment run (not yet done)
Demo
Replay of mock data: the real front end with recorded responses. No backend, no Panorama.Work tool, mock data
947unit tests, Python 3.9 and 3.13
39 of 39UI smoke test, 0 console errors
10refresh phases into SQLite snapshots
76issues settled on paper before code

Status board

4 working, 3 designed only, 1 failed or missed

Working 4

  • 947 unit tests pass on Python 3.9 and 3.13 (re-run Oct 2026); the suite grew from 248 at the first milestone.
  • Playwright UI smoke test: 39 of 39 with 0 console errors on the default mock fleet (Sept 2026).
  • Read-only by construction: XML API reads only, plus at most one key request on Test; two tests check that the source has no write patterns and a mock refresh sends no write command.
  • API keys in a local encrypted vault (AES-256, HMAC-SHA256 tag, scrypt key derivation); UI on loopback only with a strict Host check.

Designed only 3

  • Has not run against a real Panorama yet; a 24-check plan is ready for the first real run.
  • The sign-in safety model rests on unconfirmed assumptions about how a real Panorama counts refused keys and reports failed sign-ins.
  • The vault needs an independent crypto review before it holds any key beyond a lab Panorama's.

Failed or missed 1

  • An Oct 2026 re-run on a 6-Panorama mock passed 36 of 39: two fleet-size assumptions and one timing wait, not UI defects.

Problem

Each Panorama is a single pane of glass for its own firewalls, but large estates often run several, and an engineer wants one read-only view across all of them. API keys must stay encrypted at rest, and a tool that retries a bad sign-in can lock out its admin account (Palo Alto Networks advises a separate admin account for XML API access). The tool needs only Python 3.9 or later and its standard library plus one vendored AES package, and installs nothing system-wide.

What I built

A local web app with a mind-map view of the fleet, an Attention list, search and exports.

  • Read-only by construction: it sends only XML API reads (operational show commands and running-config reads), plus at most one key request on Test. Ad-hoc queries are 7 fixed show commands, and two tests check that the source has no write patterns and that a mock refresh sends no write command.
  • A refresh pulls the fleet in 10 phases into SQLite snapshots with diffs.
  • API keys sit in a local encrypted vault: AES-256 with an HMAC-SHA256 integrity tag and scrypt key derivation.
  • The web UI listens on loopback only, with a strict Host-header check.
  • Sign-in is an explicit state machine with 10 states, a cooldown and a 24-hour denial tally, designed so the tool never locks out an admin account.
panoview on mock data: six fake Panorama appliances and 69 fake firewalls drawn as a mind map, with the fleet status table and 17 Attention items; addresses blurred
Figure 1panoview, mock data: 6 fake Panorama appliances (one in Log Collector mode) and 69 fake firewalls as a mind map, with the fleet status table and 17 Attention items. Addresses blurred anyway as a precaution. Full size, 1,600 px
panoview on mock data: a firewall's detail panel with its Health block showing connection, HA, certificate, content and master-key push status; addresses, serials and timestamps blurred
Figure 2panoview, mock data: a firewall's detail panel with its Health block (connection, HA, certificate, content, PAN-OS master-key push status). Addresses, serials and timestamps blurred anyway as a precaution. Full size, 1,600 px

How AI was used

The plan came from a multi-agent research and skeptic pass (the same loop as on the method page). Claude Code then wrote the code milestone by milestone, with a review-fix pass and a Playwright screenshot review that drove the UI fixes. I set the constraints, added two safety switches after the plan was drafted (a per-Panorama API switch that is off by default, and a global Offline mode), and own the real-environment run.

Results

947 unit tests pass on Python 3.9 and 3.13 (re-run Oct 2026); the suite grew from 248 tests at the first milestone. The app is about 14,200 lines of Python plus 17,800 lines of tests and 11,900 lines of front-end code. The Playwright UI smoke test passed 39 of 39 with 0 console errors on the default mock fleet (Sept 2026); an Oct 2026 re-run on a 6-Panorama mock passed 36 of 39, the misses being two fleet-size assumptions and one timing wait, not UI defects.

panoview on mock data: instant search across name, serial and address, each match showing its device-group path and owning Panorama
Figure 3panoview, mock data: instant search across name, serial and address, with each match's device-group path and owning Panorama. Full size, 1,600 px

Status and limits

Prototype, mock-tested only. It has not run against a real Panorama yet; a 24-check plan is ready for the first real-Panorama run. The sign-in safety model still rests on unconfirmed assumptions about how a real Panorama counts refused keys and reports failed sign-ins. The vault uses standard primitives through a vendored pure-Python AES package and needs an independent crypto review before it holds any key beyond a lab Panorama's.

What I learned

76 issues were settled on paper before any code existed; I have not measured what that saved. Now the limit is a real test bed: without a real Panorama, 947 passing tests only prove the code matches my reading of the docs.