Building as a team

When several people and coding agents work on a system, source diffs alone rarely explain the whole change. Reviewers also need to know which contracts changed, which authority is required and which evidence still applies.

Septa connects those questions through typed boundaries, exact code identities and structured feedback. Small domain slices give agents a useful unit of work; explicit relationships give people a useful unit of review.

Give each change a reviewable shape

A task should name its owning actor or library, its acceptance criteria and the interactions it may change. Separate permission to edit code from permission for the resulting code to perform an operation.

For a reservation change, a review might ask:

• Does Inventory still own the stock invariant?
• Did the request or reply contract change?
• Does Checkout need any additional capability?
• Is existing durable state compatible with the change?
• Which tests were executed, reused, missing or made stale?

These questions apply whether a person or an agent wrote the patch.

Keep implementation and acceptance distinct

An agent can generate code and tests that agree with the same mistaken interpretation. Review the acceptance criteria independently. Add examples that challenge the intended policy, such as a duplicate reservation or a request for another account’s inventory.

Evidence records answer specific questions. A scripted graph test may check messages, state and effect traces. It does not establish the behaviour of your production transport, native adapter or external provider.

Treat dependency updates as changes

An exact content identity makes the selected library unambiguous. Updating it is a deliberate change with a new identity. Review its exported contracts and effects, test the consuming application, and assess any state conversion or authority change.

The local development loop can connect a library edit to a consuming application. Compatibility and activation rules still determine when that change becomes active.

Establish a shared review habit

Use review an agent’s change as a lightweight starting procedure. Retain the relevant code identities and evidence with the change. When behaviour depends on deployment or an external service, name that additional validation rather than treating a passing local suite as complete.

Start with code and evidence to see the structured workflow. Use the evidence reference when interpreting a receipt.