Plumb

Specification

dev10 · close the session

A sub-flow of A developer's workflow. Entered from dev09 · commit, naming the story, carrying a commit, a board and — where the project keeps a series — the opening reading. Exits to dev11 · push and open a pull request, carrying a cursor the next session opens from.

3 of 4 stories proven · 0 passed, not wired · 0 unproven · 1 with nothing holding them

dev10-1 hold the gate Proven

As a developer returning to work I want the close to refuse until the work is committed and the cursor filled, so that I can open where it stopped.

The tests that cite it (2)
  • tests/test_sessions.py::test_start_briefs_over_a_dirty_tree_and_wrap_up_refuses_it — passed, grounded
  • tests/test_sessions.py::test_a_refused_close_takes_no_reading_and_appends_no_history — passed, grounded
Requirements (5)
What the user needs
  • dev10-1-ur1the gate checks that work is committed and the cursor's fields are present
  • dev10-1-ur2each reason for a refusal is named, and so is the fact that nothing was written
How well
  • dev10-1-nfr1the gate is held before anything is spent or written, so a refusal costs only the time it takes to read it
  • dev10-1-nfr2the gate never checks that the work was good, that the delta was positive, or that anything was proven
  • dev10-1-nfr3committing is checked and pushing is not; a remote is somebody else's availability

dev10-2 measure what the session moved Proven

As somebody accounting for a day I want the number to come from an artifact I did not write, so that a busy session and a productive one are told apart.

The tests that cite it (4)
  • tests/test_sessions.py::test_a_session_is_the_difference_between_two_readings — passed, ungrounded
  • tests/test_sessions.py::test_a_negative_delta_is_a_result_and_not_a_fault — passed, ungrounded
  • tests/test_sessions.py::test_a_story_that_was_deleted_is_not_reported_as_one_that_broke — passed, ungrounded
  • tests/test_sessions.py::test_a_story_that_stopped_being_proven_is_reported_and_not_refused — passed, grounded
Requirements (6)
What the user needs
  • dev10-2-ur1the session is the difference between two readings: which stories became proven, which stopped being
  • dev10-2-ur2a story deleted since the open is not a story that broke
  • dev10-2-ur3a reading counts stories; a subject read per aspect is not a story that is unproven, and is never counted as one
How well
  • dev10-2-nfr1not commits, not lines, not elapsed time, not tasks ticked
  • dev10-2-nfr2a negative delta is a result and never a fault
Still open
  • dev10-2-u1whether a reading left by an earlier session is refused, or differenced and flagged as stale, is undecided

dev10-3 place the session in the history Proven

As somebody reading a delta I want to know whether today was typical, so that a story that has flickered for a fortnight is not read as one that just moved.

The tests that cite it (6)
  • tests/test_sessions.py::test_a_session_brackets_the_history_the_project_already_keeps — passed, ungrounded
  • tests/test_sessions.py::test_a_project_that_keeps_no_history_is_the_ordinary_case — passed, ungrounded
  • tests/test_sessions.py::test_a_declared_history_is_where_the_session_is_recorded — passed, grounded
  • tests/test_sessions.py::test_the_open_says_whether_today_s_move_would_be_the_first — passed, grounded
  • tests/test_sessions.py::test_a_project_declaring_no_history_grows_no_store — passed, grounded
  • tests/test_sessions.py::test_the_count_of_transitions_counts_transitions_and_not_run_markers — passed, grounded
Requirements (4)
What the user needs
  • dev10-3-ur1the session is reported as its own stretch of a history the project already keeps
What the system does
  • dev10-3-sr1the stretch is bracketed by sequence number rather than by differencing two summaries that may have passed through anything in between
How well
  • dev10-3-nfr1a project that declares no history gets the delta and nothing else; nothing is written that the project did not ask for
  • dev10-3-nfr2appending locally and transmitting to its holder stay separate, so ending a session is never an act of disclosure

dev10-4 write the cursor for the next session Nothing holds it

As a developer returning to work I want one line saying what is next and why, so that I can open where the last session stopped.

Requirements (4)
What the user needs
  • dev10-4-ur1the cursor holds the next thing and the context for it, and never accumulates a session-by-session narrative
  • dev10-4-ur2cursor.next_task names a story.id
What the system does
  • dev10-4-sr1the cursor is committed, because it travels between two sessions
  • dev10-4-sr2a state file the tool replaces is never read half-written, and the replacement stays readable by whoever could read the old one

← Every chapter