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. 01Why does a new Cogitave repository not re-declare the org's non-negotiable rules in its own AGENTS.md?

   • The floor is inherited automatically through nearest-file precedence, and a leaf AGENTS.md can only ADD project specifics - it must not restate or override the floor.Correct. Inheriting the floor is free and overriding it is impossible; a leaf file can only add, so restating it is redundant and forbidden.
   • Each repo is free to pick which of the org rules apply to it.Incorrect. The seven non-negotiables are a floor, not a menu - they apply the moment the repo exists, and a leaf file cannot relax them.
   • AGENTS.md is optional, so small repos simply omit the rules.Incorrect. The floor is inherited whether or not the leaf file adds anything; the file exists to add project specifics, not to opt out.

2. 02A repo is classified as a hosted service. Which standards apply to it?

   • The always-on standards apply to every repo, and because its product type is a service it additionally inherits conditional standards such as product-core-baseline.Correct. Standards inherit in two tiers: always-on unconditionally, plus a conditional set switched on by the product type.
   • Only the standards the author chooses to list in the repo's config.Incorrect. Standards are inherited by tier and product type, not hand-picked per repo.
   • Every standard in the index applies equally to every repo regardless of type.Incorrect. The always-on tier is universal, but the conditional tier is switched on by product type - an OSS library and a SaaS service inherit different conditional standards.

3. 03How does a new repo get the baseline 'baked in from birth' rather than assembled later?

   • It is created by copying templates/base - the toolchain, the quality gate CI also runs, the CI/CD wiring, and the pinned .claude plugins - then layered with its per-type template.Correct. The repo is born from the template with the ruleset already present, so it never has to assemble its own toolchain.
   • A CI job installs the rules automatically after the first push to GitHub.Incorrect. The scaffold is present from the first commit via the template; and at Day 0 nothing has been pushed to GitHub yet - enforcement turns on at cutover.
   • Each contributor configures the hooks, commitlint, and CI by hand in every repo.Incorrect. That per-repo hand-assembly is exactly what the scaffold removes - templates/base ships the same checks CI runs.

4. 04You need a background job in a new service. What does discover-before-generate tell you to do first?

   • Query the patterns catalog for the canonical pattern, follow its governing standard and reusable artifact, and only author something new after a recorded 'no fit' - then contribute it back.Correct. Reuse is the default; building from scratch is the justified exception, and a genuinely new pattern is contributed back so the next project finds it.
   • Write it from scratch, since every repo's needs are different anyway.Incorrect. Building from scratch is the exception that must be justified and recorded, not the default starting move.
   • Copy the closest-looking code you can find and move on without recording anything.Incorrect. Going off-road is allowed, but it is a decision with a cost: you record the rationale, own the maintenance, and still satisfy the Definition of Done.