A signed-in Improver should be able to make sense of their own involvement activities at a glance. That was the starting point for a feature I built through the Stage 4 harness: a Highlights view in the Involvement Stories tab.
The story asked for three things:
As a signed-in Improver, I want to see the single biggest contribution, the activity type I do most often, and the activity type that earns me the most points.
I know it looks like an incomplete story; this is how it was captured by the harness at the time and I left it like that for the post to show an example of progress over perfection.
It sounds like one summary card. The story actually describes three different measures, and the difference between them matters.
Three measures, not one score
The first highlight is the user’s biggest single contribution. The second is the activity type they do most often, measured by count. The third is the activity type that earns them the most points, measured by points.
Those last two can be different. Someone can do one kind of activity frequently and earn more points from another kind. If I collapsed them into a single notion of “top activity,” I would lose the distinction the story asked the feature to show.
The view presents the highlights for All Time and for a selected recent period. That gives a person a way to compare their long-term pattern with what they have been doing lately. I wanted it to be useful as a reflection tool, not just a collection of numbers.
The selected period also matters to the meaning of each card. The highest point total for All Time may differ from the activity that earned the most points last year. The labels and columns had to make those scopes clear so the person reading the page could tell what each result described.
The feature story kept the three measures separate and limited the view to the signed-in person’s involvement.
The boundary was part of the behavior
The feature should show the signed-in person’s own data. A manager may have access to direct reports’ information in another part of the product, but that does not mean this view should return anyone else’s activities. I had to make that boundary explicit in the story and in the checks.
The API integration test authenticated a request and checked that the response contained the three distinct highlights. That gave me evidence for the API contract: the request was accepted for an authenticated user and returned the expected shape. It did not, by itself, prove every access-control case.
It also did not prove that the page presented those values in a way people could understand. A response can contain three fields and still lead to a confusing screen if the UI hides whether a value is a count or a point total.
I wrote about choosing the right unit to evaluate in Testing the Wrong Unit. Here, I needed evidence for both the API response and the experience a signed-in person would see.
The journey test exercised the experience in the browser. It checked that a signed-in user could open the Stories tab, see the three cards in each time period, and see that most-frequent activity and highest-points activity were not accidentally treated as the same measure. It also checked that another employee’s activities did not appear.
That last scenario matters because a happy-path test can pass while the feature still shows information to the wrong person. I wanted the test to express the boundary, not leave it as an assumption hidden in the implementation.
Keep the evidence in scope
This was one Highlights slice within a larger Involvement Stories feature. The Stage 4 records show the slice passing through the plan, implementation, tests, verification, and logging steps. The aggregate test counts in the feature-set summary belong to the whole set, not just to Highlights, so I do not attribute them to this one slice.
The UI was also intentionally scoped to React. A deterministic guardrail against out-of-scope frontend paths was already in place before these Stories slices. That is evidence about this feature workflow. It is not proof that every other part of the application behaves the same way.
The distinction matters when I talk about the result. The harness helped build and verify this slice under a defined scope. It did not certify every screen in the application or remove the need for a person to review the finished experience.
I described the broader harness and its checks in Building a Development Harness I Can Trust. That post explains the workflow. This example shows what the workflow had to preserve as it moved from a story to a feature: three distinct measures, the right person’s data, and a test that checks the boundary.
The AI Maturity Model playlist and Stage 3 to 4: The Arrows on the Workflow Map put this work in context. The arrows matter because the test step needs to inherit the story’s intent, not just exercise whatever code the implementation step produced.
When I review a feature like this, I want to recognize the promise made in the original story in the behavior on screen. The three highlights remained distinct, and the data stayed personal. That is what I wanted the harness to carry all the way through.
Leave a Reply