Owner knowledge that changes code

01 / Describe what you do, step by step

An editor finishes an interview, selects part of a recording, starts transcription and marks the beginning and end of a quotation. The text is already visible. The next step is to add it to the story. Yet the application requires the editor to open the same transcript again elsewhere. To the code, that may be a valid condition. To the person, it means repeating completed work.

The owner of a workspace knows how the job actually unfolds. The most useful feedback need not say “change this function”. A precise account of the steps, the stopping point and the intended next action can be enough. Two historical cases from the development of Szpieg+ show how that conversation becomes a code change.

02 / Case one: the text is already open

In a conversation on 15 September 2026, the owner described the path from a recording to a selected passage. The problem was how the application recognised an open transcript. The earlier condition looked for it in one particular view. Text available elsewhere in the interface did not meet that definition.

A change recorded that day also checks for an active container associated with the correct file. The container must still belong to the page document; a remembered name alone is not enough. This lets the code recognise a transcript opened outside the previously supported view. It is a specific change to a condition, rather than just new button text.

What remained matters: adding a passage still requires the file and the transcript revision. A more convenient route should not lose the information identifying the text from which a selection came. This case does not establish that any passage from any window can be accepted without checks. It shows a correction to an overly narrow definition of an action already completed.

03 / Case two: automation occupies the workstation

The second conversation concerned a local background transcription process, called an “ant” in the workspace. Its reservation protected the task against collisions. When the process was already running, the interface displayed a warning and stopped the user from proceeding. The owner needed a way to take over deliberately, even if that meant abandoning work in progress and ordering paid transcription.

The historical code change made that route available for both waiting and running tasks. For work in progress, the dialog describes the consequences: interrupting the process, losing completed work and starting the paid route. The confirmation button distinguishes interrupting work from releasing a reservation. The person is meant to receive a choice together with its cost.

This describes the interface change and its design intent. A dialog alone does not prove that every execution path requires confirmation. The function we read also has a fallback for an unavailable dialog mechanism. We therefore do not present the change as a complete, tested safeguard. Acceptance testing of a takeover must cover that situation and the actual termination of the process as well.

04 / Two changes, two different conditions

The first case removes redundant repetition: the application recognises an action completed in another view while retaining the revision link. The second returns a decision to an authorised person while showing the consequences of interrupting automation. Both draw on knowledge of human work, but neither supports a universal rule to “remove the block”.

“Do not make me open it twice” does not mean “forget the revision”. “Let me take over” does not mean “omit the cost warning”. Write down that distinction before asking an agent to implement the change.

05 / What the evidence establishes

The sources are an internal brochure dated 16 September 2026 and a direct reading of two changes in the code history dated 15 September. In each case, the stated need was compared with the corresponding difference between revisions. We publish a paraphrase and an original diagram, without full conversations, private identifiers or recording content.

The evidence supports a limited statement: a particular need was described, and a corresponding change was recorded in code. It does not support a calculation of time saved or errors prevented. We performed no new production test for this edition. For the second change, the historical record explicitly left deployment to the owner's decision; we do not turn that record into a claim about the service's current state.

06 / How to review a similar change

For the first case, open a transcript in each supported view, select a passage and check its association with the correct file and revision. Separately check a missing revision and a stale view. Record the expected outcome before running the trial.

For a task takeover, check automation waiting and running, cancellation, confirmation and an unavailable dialog separately. Check that the warning matches the actual cost and that the earlier process really stops doing the work. This is a proposed acceptance plan, not a list of tests performed for this article. The agent authority card helps establish who may make that decision.

07 / A small change card for the leader

Record five things: what I am doing, where I get stuck, what I want to do next, which condition must remain and how I will recognise improvement. Attach the input revision and acceptance evidence. This gives an agent a concrete problem and boundaries for the solution. Separating code checks from human review helps avoid drawing broad conclusions from a passing test.

If your workspace has a similar “I have already done that” moment, we can start by reconstructing one workflow. A neutral description of the actions and the obstacle is enough. Implementation details can be discussed in conversation without publishing private data or entire sessions.

08 / Provenance and corrections

Sources were checked on 25 September 2026. This is a study of historical decisions, not a manual for the current version of Szpieg+. The original brochure was prepared with contributions from Codex and Claude Code. Codex prepared this public Polish/English adaptation, the diagram and the author review; no independent second-model review or production measurement was performed.

No third-party illustrations or recordings were used. Human oversight includes withdrawal after publication. A discovered conflict between a conversation and the code change, new deployment evidence or takeover acceptance results trigger another review. Any new result needs its own date and scope.