Questions, scenarios and what to deliver

10. Questions the model must answer

These are not requirements.

• Are prereleases reported, and when: only where the pin is a prerelease, or where a tier asks for them (8)?
• What does a report say of a release its source has withdrawn, and of a pin whose own release has been withdrawn (43)?
• Do advisories wait on a tier’s cadence, or is every pin’s advisory looked for at every scan (15, 18)?
• Is an acknowledgement each person’s, or the repository’s, and does it travel to another host that shares the repository (20, 28)?
• Where does the held state live when several hosts share one repository (28, 50)?
• How does a repository holding several projects declare one tier across all of them, and is one dependency in two projects one dependency or two (2, 13)?
• Is a cadence measured from a complete scan’s start or its end (15)?

11. Scenarios the model must satisfy

• S1. A colleague opens a session in a repository that declares its packages and its Python requirements. Two dependencies of the favorites tier have newer releases, and the session is told of both with their notes. Nothing in the repository changes.
• S2. The same session starts again an hour later. No tier is due, no source is reached, and the session is told the same two releases and when they were found.
• S3. One favorite’s source cannot be reached. The report names it unread with the reason, reports the other favorites, and the tier is still due at the next start.
• S4. A fixer moves one favorite to its newest release, and the change lands. The next scan no longer reports that release, and no acknowledgement was given.
• S5. A person dismisses a release. No later report holds it. When a newer release is published, that one is reported.
• S6. A recorder asks for the favorites’ releases every day. A release is reported every day, under the same identity, until its pin moves, and the recorder keeps it once.
• S7. A release’s notes run to forty kibibytes. A report that holds it and a brief for it give the notes whole, or the part asked for and a way to read the rest, and not one word is changed.
• S8. Two checkouts of one repository scan at once. The held state afterwards is one of theirs, whole, and every acknowledgement stands.
• S9. The held state is deleted, apart from its acknowledgements. The next scan reports exactly what the last one did, at a new time.
• S10. An advisory names a pin. Every report that holds the dependency names the advisory, though a person dismissed the release that would fix it.
• S11. A watch list names fourteen tools by their upstream repositories and tag patterns. Each release is reported under the same identity a declaration of that tool would give it.
• S12. A person asks through the command line, an agent through its session and a pane through its sidebar, about one repository state. All three get the same report.

12. What to deliver

A model of headwater that satisfies Parts A and B: its components, the answers each surface gives, how a scan is made and a report derived, with fixed examples, and how a dependency description, a release source and a store are added. A conformance suite whose scenarios each cite the clauses they exercise, failing when a clause is cited by nothing. The profiles of Part C, each passing the suite.