Knowledge check

Check your knowledge

Choose an answer to see why it is right or wrong.

JavaScript is off, so every explanation is shown at once.

1. 01A pattern entry's error-handling.md and the api-design standard it cites disagree on how a validation failure should be shaped. Which wins, and why?

   • The standard wins, and the pattern is treated as a bug. A pattern entry only REFERENCES its governing standard(s) - it never restates them, so the standard is always the single authority.Correct. ADR-0022 (part A2) is explicit: if a pattern and its governing standard disagree, the standard wins and the pattern is a bug to fix; patterns/README.md conveys the same pointer-not-policy principle, because the catalog is a pointer, never a second copy of policy.
   • The pattern wins, because it states the one canonical, concrete solution and the standard is only background reading.Incorrect. The catalog is deliberately a thin, honest pointer. The rules live in the governing standard; the pattern entry never outranks it.
   • Neither wins - you escalate to an ADR before writing any error-handling code.Incorrect. An entry disagreeing with its own governing standard is a defect in the entry, not a genuine open design question requiring a new ADR.

2. 02In catalog.yaml, the new-service-rust entry carries a canonical_pattern field pointing to service-scaffold.md. What does that field mean?

   • This intent is one of several that share the same five-section canonical pattern doc - service-scaffold.md is the authoritative Problem / Cogitave-way / standard / artifact / anti-pattern write-up, and the catalog.yaml row is a shorter, task-specific pointer into it.Correct. Several catalog.yaml intents (new-repo, new-service-rust, new-service-go, new-library) all set canonical_pattern to service-scaffold.md, because they are variations on one canonical pattern doc rather than separate policies.
   • The entry is deprecated and superseded by the pattern it names.Incorrect. Supersession is a distinct, explicit relationship (supersededBy) in the catalog's design; canonical_pattern is not a deprecation marker.
   • The entry has no governing standard of its own, so it borrows one from the linked pattern instead.Incorrect. The entry still lists its own governing_standard list; canonical_pattern additionally names the five-section doc that carries the full write-up, it does not remove the entry's own standard references.

3. 03You are about to add a background job. Per the catalog's discover-before-you-build loop, what is the correct first step?

   • Query the catalog for the task - "do work off the request path" - before writing any code, then open the matching entry and follow its two links: the governing standard and the reusable artifact.Correct. Step 1 of the loop is query before you generate. Only after finding and reading the entry do you follow its governing standard (background-jobs pattern: reliability, product-core-baseline) and its reusable artifact (the worker entrypoint + idempotency primitive).
   • Write the job the way that feels natural, then check afterward whether a pattern already existed.Incorrect. That is checking after generating, the exact inversion of discover-before-generate; building from scratch is meant to be the justified exception, decided before you write code, not a default you audit in hindsight.
   • Copy the code of a similar-looking job from another repo you remember, without opening the catalog at all.Incorrect. Copying an unrelated repo's ad-hoc implementation is exactly the anti-pattern the background-jobs entry calls out - fire-and-forget work with no idempotency, retry, or dead-letter story - because it skipped the catalog and its governing standard.

4. 04You searched the catalog and no existing pattern fits your problem. What does the catalog require of you before you build from scratch?

   • You may go off-road, but it is a decision with a cost: you record the rationale (an ADR or a lifecycle evaluate note), you own the ongoing maintenance, and you still have to satisfy the Definition of Done.Correct. Step 4 of the loop states this exactly: deviating is allowed but is a decision with a cost, not a silent default - and ADR-0022 (part A3) plus the reuse-first standard add that a genuinely new, industrial-standard solution should be contributed back so the next project finds it.
   • Nothing - patterns are optional suggestions, so building from scratch needs no rationale or record.Incorrect. Building from scratch is the exception that must be justified, not a cost-free default; recording the rationale and owning maintenance is required, not optional.
   • You may build from scratch only after a human manually deletes the closest catalog entry so it stops looking like a fit.Incorrect. Deleting or hiding an entry is not part of the loop and is not how the catalog handles a genuine gap; a recorded rationale (ADR or evaluate note) is the actual requirement, and the entry itself stays intact for the next reader.