Skip to content

Latest commit

 

History

3 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Portwell Assist Digest

The daily support digest for Portwell account managers, and the demonstration project for Advanced SDLC and harness engineering (introductory class, 2026-09-04).

Two things live here at once. It is a small working reporting tool, six modules and 29 tests. It is also the repository in which one bounded change is taken through a full agentic delivery lifecycle in front of the cohort, so that the evidence produced at each stage can be inspected rather than described.

Setup

uv venv .venv
VIRTUAL_ENV=.venv uv pip install -e '.[dev]'
.venv/bin/python -m pytest -q
.venv/bin/python -m digest.cli

What it does

# Support digest, 2026-08-01 to 2026-08-31

356 tickets closed across 10 accounts.
Metric definitions: first_response_minutes_p50 v1.

| Account              | Tier       | Region | Closed | First response p50 |
| Sunder Retail Supply | enterprise | NA     |     96 | 122                |
| ...                  |            |        |        |                    |
| Fjordline Depot      | standard   | EU     |      2 | below the minimum volume for this measure |

Four accounts fall below the minimum denominator the metric definition declares, so their figure is suppressed with a reason instead of being reported as a median over four tickets.

The demonstration

The change: put deflection_rate per account into the digest, at a pinned version, suppressed below 20 closed tickets. It is small enough to complete inside a session and large enough to have a real specification decision in it, an architecture rule that the obvious implementation breaks, and a boundary the obvious implementation gets wrong.

Read For
.context-index/specs/features/digest/deflection-in-digest.intake.md The request as it arrived, what intake established, and the decision intake could not make
docs/demo-runbook.md How to run the demonstration, what to show at each stage, and what to do when the live run goes sideways
docs/demo-recorded-trace.md The captured run: eight stages, two refusals, the corrections, and the final state

The captured trace exists because the production notes require the demonstration to expose one recoverable failure, and a live run cannot be relied on to fail in the same place twice. It is a fallback and a reference, not a script to read out.

Repository layout

src/digest/                     six modules, one direction of dependency
tests/test_architecture.py      the four architecture rules, read from the source
fixtures/warehouse/             the analytics warehouse, as CSV
fixtures/metrics/               the metric definitions this project consumes
.context-index/                 the ADEV context layer: constitution, specs, governance, state
docs/                           the runbook and the captured trace

Relationship to the track repositories

This project shares the Portwell canon with the four track repositories in ../track-*: the same ten accounts, the same product areas, the same metric definitions, the same two pilot incidents. It is a different service from the one the SDLC track inherits, on purpose, so that demonstrating the lifecycle here does not hand the SDLC track its answers.

About

Demonstration project for the Advanced SDLC and harness engineering course

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages