This template codifies the section patterns that have emerged across 40+ dev log entries. Use it as a guide for consistency, but adapt freely when the session calls for different structure.

Flexibility: If a particular session needs different sections or organization, use your judgment. This template captures common patterns, not rigid rules. Examples of when to diverge:

• Investigation-heavy sessions may need more "Discovery" sections
• Multi-issue sessions may need per-issue subsections
• Planning sessions may emphasize "Design Decisions" over "Implementation"
• Quick fixes may not need full structure (but document them anyway!)

1. Every commit must be fully human tested before hitting the repo.

You must be able to confidently say: “This commit does what it’s supposed to do, and does not either contain obvious regressions or introduce new bugs”. You have proven this to be true because you have tested the commit in the app (or browser or other relevant client), whilst also testing all reasonable combinations of related functionality to ensure there are no obvious regressions.

There should be no surprises. Regressions and new bugs should be limited to rare edge cases and unexpected conditions that fall outside of the range of normal user interaction with the app.

2. Each commit should be considered complete, in the sense that is a functional, tested, and shippable chunk of work.

Note that this does not mean that the commit needs to contain a completed feature, nor a completed sub-unit of a feature. It might only contain a single line change. But it must be confirmed that it leaves the p

• The server’s customers are the mobile apps.
• The mobile apps’ customers are the end users.

• The server should deliver updated product / functionality to its customers (ie the mobile apps) on a daily / timely basis.
• The changes / additions should be documented to ensure basic understanding of how to make use of them.
• The changes / additions should be delivered in a stable and shippable state.
• The server’s customers should never need to be aware of the inner workings of the server.
• The server’s customers should never be required to run an instance of the server locally.

1. All else being equal, a simpler system is preferable to a more complex system.
2. Complexity, structure, process, and size should only be added after a problem is identified.
3. Such additions should attempt to solve the identified problem only. Avoid scope creep.
4. If the problem can be solved by reducing rather than adding complexity, that solution is preferable.

A project or team should only have the structure, complexity, processes, and size necessary to solve identified problems, and no more. Start with the simplest form, and add to it only when necessary.