Netwise — Arsh update #6 #274

Follows #175. Eleven days, and the product changed more in them than in the
three sprints before. Everything below was measured today, not remembered --
if a number here disagrees with pytest or the API, believe those.

main   c9ee421   1030 passed, 8 skipped   ruff clean   CI green

What the product can do now that it could not on the 20th

Four things, and each is paired with the measurement rather than a description.

The AI's second direction exists (#13, #14). The client asked for two:
explain findings, and take a plain-English instruction and propose a change,
pushing back if it opens something. The second one now works:

"allow any to any on any on rtr-us5"

  on the secured config     WARNING -- 2 high-severity simulated impacts
  on the insecure config    "no change detected"  (honest: it already permits it)

A user's own policy reaches a check (#181). policy_compliance asserts
your rules instead of our examples, and every finding says which of the two
produced it. Policy-driven detections on a network that is not ours: 3 -> 8.

The client's own vendor produces a finding (#216). This is the one I would
lead with on Thursday. A converted PF Sense export used to report three "could
not check" cards and nothing else -- not because conversion failed, but because
our rules name rtr-us5 and the converter emits pfsense-us5, and those never
meet. With a policy naming the converted device:

PC-001  found  high  The LAN can reach the internal server
        device     pfsense-us5
        detail     Flow start=pfsense-us5 [10.10.10.0:49152->10.20.0.5:443 TCP
                   (SYN)] is permitted but policy requires it to be DENIED
        explained  yes (model)

The AI layer is live on the demo machine. Ollama installed,
netwise-warden built. Measured over six scans: 33 cards, 33 model-written,
0 fallback.

The nine-beat demo was re-run at the 2026-09-01 gate

Against current main:

main   2a2f957   preflight READY   netwise-warden:latest present

Browser automation was not available from this Codex environment (agent.browsers.list() returned []), so I did not claim a driven-Chrome run. I did the gate through the live local server plus the real frontend report-download harness:

1  page load                                  200 OK
2  upload secure config                       staged, not analysed yet
3  Scan Now on secure config                  0 found / 2 none / 1 error
4  ask: Can rtr-us5 reach 10.20.0.5?          grounded; DENIED_IN
5  propose: allow any to any on any           warning=true; 2 impacts; permit ip any any
6  HTML report button URL                     200 OK from /api/report?format=html
7  upload insecure config                     staged, not analysed yet
8  Scan Now on insecure config                5 found / 0 none / 1 error; 5 model / 0 fallback
9  PF Sense export + user policy              PC-001 found; 1 model / 0 fallback
9b CSV report button URL                      200 OK from /api/report?format=csv

Machine time for the measured local sequence was about 18s after services were already warm. The important demo correction is that beat 9 is no longer a typed URL: tests/test_report_download.py drove the real web/static/app.js report-control harness and passed 25 passed, including the available-link and unavailable-link states.

Targeted support checks also passed:

23 passed   tests/test_web_propose_endpoint.py
            tests/test_web_ask_endpoint.py
            tests/test_web_policy_applied.py
            tests/test_pfsense_policy_join.py

What changed from the previous run sheet: the first-scan warning remains worth narrating, but it was not slow on this warm run; the report download is now a visible button path; and the PF Sense + user-policy beat is showable as a real finding, not only as a claim in the status text.

What I actually spent the time on, including the unflattering half

62 PRs merged since update #5. The split is the point:

Arsh      36        Shubham   11
Ankeet    10        Samika     5

58% of them are mine. That is #249, which I filed on myself: I author most
of the PRs and give fewest of the reviews, and I consume most of the team's
review capacity. The rule that came out of it ? review before authoring --
is why the last three days look different:

#269  approved            #268  approved            #265  approved
#262  approved            #257  approved            #252  approved
#263  approved            #255  changes requested

Eight reviews since the 28th, and I ran the code in every one rather than
reading the diff. Three found things a green tick would not have:

• Report export UI: the download control for #222 #262 -- the download control broke 25 tests in a file it never touched.
  @SamikaPerera had added a DOM shim to the five harnesses that existed when he
  wrote it; a sixth arrived with Business-context risk scoring: escalate severity by asset criticality (#237) #254 afterwards. Eleven lines fixed it, and it
  is merged.
• Phase 1.2, phase A: link explanations to the evidence they came from #255 -- @patelankeet2's provenance links survived three mutations, but
  renderImpact() calls renderFinding() with one argument fewer than the new
  signature, so the propose pane renders id="undefined" twice.
• deps: bump the runtime group across 1 directory with 2 updates #204 -- the pybatfish bump produces identical results, but the pin's
  contract is that client and container versions match, and the container has
  not moved. Pull the image first.

Two false claims about our own agreements, found on the last day

Both were being used while being wrong.

CLAUDE.md said   "F-1 amendment A-2 -- RATIFIED by all four"
the contract      Shubham OK  Arsh OK  Samika OK  Ankeet NOT AGREED   3 of 4

CONTRIBUTING.md   M-2 quoted as settled in CLAUDE.md section 7b
the table         1 of 4 -- and I had been citing its three rules in reviews
                  and merges all week with my own row blank

A ratification recorded as complete when it is not is the worst place this
project's recurring fault has landed, and it sat under the heading "Settled --
do not reopen without the team", which is the one heading that stops anyone
checking. Both corrected in #270 and #272.

@patelankeet2 -- A-2 has been waiting on your signature since 13 August.
Not a complaint: nothing notified you, which is #231. It is one tick.

Waiting on people, one name each

I have four PRs open, which is more than #249 says I should. Two of them I
opened without requesting anyone, which is my own miss and now fixed.

None is urgent. If you only look at one thing this week, make it #263 or
#255 -- your own work is further along than mine.

Decisions

#266 -- decided. @SamikaPerera agreed option 1 and is taking both renderers
in one PR. His condition is sharper than my proposal was: the reword must
specifically distinguish "we checked and found nothing wrong" from "you gave
us zero rules, so nothing was checked" -- not just softer phrasing. He is
right, and a vaguer label would have blurred the distinction rather than fixed
it.

#234 -- no objection, deadline Wednesday midday. Defer until after the
client meeting; the demo machine cannot reach the broken state.

Sprint 5 -- no objection, same deadline. It is 35/43 and five days overdue.
Proposal: close it at what it reached, move six issues to Sprint 6, and take
#87 out of sprint planning entirely -- it has been carried through two
sprints unstarted because it is not sprint-sized.

The record is written and up for review as #273, before the milestone
closes rather than after. It says plainly that three things about how this
sprint was run were mine: five unassigned items admitted against a rule I
wrote, the record not written inside the sprint, and five days past due with no
decision either way. The suite went 384 -> 1030 in the same window. The
sprint delivered; it was run badly, and those are two different sentences.