Knowledge check Choose an answer to see why it is right or wrong.
JavaScript is off, so every explanation is shown at once.
01 A change passes a teammate's local pre-commit hook, but the identical commit fails the same check in CI. What does development-process say this means?
The parity contract - lefthook commands == CI commands == just targets - is broken somewhere; since the hook and CI are meant to call the same just target through the same pinned .mise.toml toolchain, this is a parity bug, not a flaky test, and the fix is to close the gap, never to relax CI. Correct. Drift between hook and CI is the exact bug development-process exists to kill; there is deliberately no fourth, hand-written copy of the command. This is expected, because the pre-commit hook and CI are unrelated tools that happen to run similar checks. Incorrect. The standard's load-bearing rule is that they run the same command through the same toolchain; if results diverge, something is genuinely broken, not merely coincidental. The correct fix is to relax the CI check so it matches whatever the more permissive local hook allows. Incorrect. CI is the real, unbypassable gate; the hook is only a bypassable convenience. Loosening CI to match a local pass would remove the actual gate, which is the opposite of the fix. 02 How does ways-of-working.md describe its relationship to development-process.md?
Ways-of-working is the outer loop that sits above the inner-loop toolchain (edit -> build -> test, in seconds) and uses the request-lifecycle Request as its unit of work; it composes with the inner loop rather than replacing it. Correct. The two documents are explicitly layered: the outer loop plans and flows the same Requests the inner loop's implement stage builds and tests. Ways-of-working replaces development-process's pinned toolchain and canonical just targets with a new set of tools. Incorrect. Ways-of-working is about planning and flowing work, not about the toolchain; it does not touch mise, just, or the parity contract. The two documents describe unrelated, non-overlapping parts of the estate with no cross-link between them. Incorrect. Ways-of-working explicitly cross-links development-process as the inner loop it sits above, and reuses its DORA/SPACE measurement rather than inventing a second one. 03 Per ADR-0025, why was Scrum rejected as Cogitave's base internal engineering method?
Fixed sprints batch work against trunk-based continuous delivery, velocity is a trivially gamed metric that is meaningless once agents are team members, and Scrum's ceremonies and roles exist to manage a coordination problem this small, autonomy-by-default team does not have. Correct. This is the ADR's stated reasoning: the failure modes (batching, gameable velocity, human-only roles and ceremony) actively hurt a team on trunk-based CD with agents pulling work continuously. Scrum was rejected because ADR-0025 concludes it is a flawed method that no team should ever use. Incorrect. The ADR is explicit that Scrum genuinely fits newer teams needing scaffolding or fixed-scope, stakeholder-heavy work; it is rejected as the wrong fit for this team, not condemned in general. Scrum was rejected purely because Cogitave could not staff a dedicated Scrum Master role. Incorrect. Staffing a role is never cited as a reason in the ADR; the stated reasons are sprint batching against trunk-based CD, gameable velocity, and ceremony built for a coordination problem this team lacks. 04 In the flow-based model, agents pull and execute most Requests unattended. What does the WIP limit actually protect, and when does a human get involved?
The WIP limit protects the scarce human-attention budget - items awaiting review, sign-off, or the exception gate - not raw agent throughput; a human is pulled in only on an exception (a failed check, low confidence or novelty, drift or a policy violation, or a transition in the always-human set), not as a routine checkpoint on every item. Correct. This is the stated purpose of the WIP limit in the flow-based model: it exists so human review never becomes a silently-growing queue, while in-spec work runs unattended. The WIP limit caps how many agents may run concurrently, and every item still needs a human's approval before advancing to the next stage. Incorrect. The limit is about the human-attention budget, not a cap on agent concurrency, and a human is deliberately not asked to sign off at every boundary - only on an exception. The WIP limit is a vanity metric used to rank how much work each individual contributor completes. Incorrect. Flow metrics are explicitly the honest, hard-to-game alternative to individual ranking; a WIP limit is a flow-management control, never a leaderboard input.