docs(phase-3): the four open questions are answered; required set is eight

The proving consumer answered Q1-Q4 on 2026-07-25, each measured or read out
of their code that day. No row in the mapping moved. Three of the four answers
carry a sharper reason than this table drafted, and one reverses a correction
this table made a day earlier.

Q2 is the substantive change. This table had corrected the plan's eight-key
required set down to four, against the consumer's REQUIRED_KEYS constant.
Their operator ratified eight: the constant is their emit-path minimum, not
their contract, and all eight keys are present on 522/522 of their documents.
STRICT_V1 is therefore deliberately stricter than the consumer's own
validator; if they ever ship a class lacking source_sha they bump the profile
rather than bend the bundle, and they say so before shipping it. The eleven-key
allowlist is unchanged and still a different thing from the required set:
version/date are layer-specific and summary is the one nullable key, so all
three stay optional-when-absent.

Q1, Q3 and Q4 keep their Consumer/Guard assignments, now with the reasons that
justify them: gate 5 escalates on run state (disposition == verbatim) rather
than document class, so a profile structurally cannot see it; gate 4's
changelog rule is a vendor slug list that is not scoped to concepts/ at all;
gates 19 and 22 need external state, one of them by construction never
blocking. Assumption C2 is confirmed at 25 gates and the index shape is
confirmed non-negotiable.

Both reviews - the consumer's and the operator's - are now in, so the port may
begin. The Guard column is unaffected by all of it.

docs/plan/phase-3-configurable-contract.md

@@ -19,10 +19,10 @@ the golden suite is the regression harness for that claim.
    - `type_policy`: closed enum vs. open set; the reserved `verdict` exclusion
      stays unconditional (it is a spec invariant, not profile config).
    - `frontmatter_schema`: three distinct fields, not one — the *required* key
-     set, the *allowlisted* key set, and the canonical emission *order*. The
-     proving consumer keeps four required keys inside an eleven-key allowlist
-     (see `docs/phase-3-split-table.md`), so a single ordered required/optional
-     pair cannot express it. Also carries nullable keys and the scalar encoding
+     set, the *allowlisted* key set, and the canonical emission *order*.
+     STRICT_V1 requires eight keys inside an eleven-key allowlist (see
+     `docs/phase-3-split-table.md`), so a single ordered required/optional pair
+     cannot express it. Also carries nullable keys and the scalar encoding
      subset. Phase 1's seven-key layer and Phase 2's inbox layer are
      expressions of this schema.
    - `path_policy`: layer/path prefixes, filename namespaces, reserved filename
@@ -39,16 +39,19 @@ the golden suite is the regression harness for that claim.
 2. **Built-in profiles:**
    - `DEFAULT` (implicit): exactly the ingest-spec v1 + Phase 2 contract.
    - `STRICT_V1`: the `claude-code-llm-wiki` contract — closed type enum
-     (`Concept`/`Guide`/`Reference`/`Release`), four required frontmatter keys
-     (`type`, `title`, `description`, `timestamp`) inside an eleven-key
-     allowlist that doubles as emission order, layer/path/type/source_tier
-     agreement rules, `log.md` required-absent, `README.md` reserved-exempt,
-     per-directory indexes, and root-index metadata (`okf_version`,
-     `bundle_profile`, `okf_spec_commit`).
+     (`Concept`/`Guide`/`Reference`/`Release`), eight required frontmatter keys
+     (`type`, `title`, `description`, `timestamp`, `layer`, `source_tier`,
+     `source_url`, `source_sha`) inside an eleven-key allowlist that doubles as
+     emission order, layer/path/type/source_tier agreement rules, `log.md`
+     required-absent, `README.md` reserved-exempt, per-directory indexes, and
+     root-index metadata (`okf_version`, `bundle_profile`, `okf_spec_commit`).
 
-     An earlier draft of this line listed eight required keys. That was the
-     allowlist read as the required set; corrected against the validator on
-     2026-07-25.
+     This line was drafted as eight, corrected to four against the consumer's
+     `REQUIRED_KEYS` constant on 2026-07-25, and settled at eight by their
+     operator the same day: the four-key constant is their emit-path minimum,
+     not their contract, and all eight are present on 522/522 of their
+     documents. STRICT_V1 is therefore deliberately stricter than the
+     consumer's own validator; the split table records the agreed consequence.
 3. **Plumbing change:** materialization, inbox, import, and index generation take
    an optional `profile` argument defaulting to `DEFAULT`. No behavior branches
    outside what the profile object expresses.