ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
996e64cb93
TenantAtlas/specs/438-exchange-internal-render-model-slice-1/checklists/requirements.md
Ahmed Darrazi 996e64cb93
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 6m3s
Details
docs(spec): defer Spec 438 close-out
2026-07-10 15:26:48 +02:00

12 KiB
Raw Blame History

Requirements Quality Checklist: Spec 438 - Exchange Internal Render Model Slice 1

Purpose: Validate that Spec 438's requirements are complete, unambiguous, internally consistent, measurable, repo-grounded, and implementation-ready. This checklist tests the requirements writing, not the implementation. Created: 2026-07-10 Feature: spec.md

Candidate And Prerequisite Quality

  • CHK001 Is the candidate source identified as directly user-provided rather than an invented queue item? [Traceability, Spec Preparation Selection Summary]
  • CHK002 Is the Spec 437 prerequisite stated with merged PASS/merge-ready evidence and current HEAD? [Completeness, Spec Preparation Selection Summary]
  • CHK003 Is the completed-spec guardrail explicit for Spec 422 and Specs 429-437? [Consistency, Spec Preparation Selection Summary]
  • CHK004 Is the stale dev versus current platform-dev base decision disclosed? [Assumption, Spec Preparation Selection Summary]
  • CHK005 Does the Candidate Check acknowledge zero current consumers and zero visible product outcome? [Clarity, Spec Spec Candidate Check]
  • CHK006 Is a current-release operator workflow or real consumer demonstrated for this standalone layer? [BLOCKER: no; PROP-001, Spec Spec Candidate Check]
  • CHK007 Can the topic be described as an independent current operator problem rather than a sub-operator implementation slice? [BLOCKER: no; Spec Approval Rubric Rule C, Spec Spec Candidate Check]
  • CHK008 Does the candidate gate use the exact Defer classification, an evidence-based 5/12 score, and FAIL instead of allowing technical boundedness to override the constitution/rubric blocker? [Consistency, Spec Spec Candidate Check]

Scope And Proportionality Quality

  • CHK009 Is exactly one local builder proposed and every broader abstraction explicitly forbidden? [Scope, Spec Proportionality Review]
  • CHK010 Are the three supported resource types named exhaustively? [Completeness, Spec Functional Requirements]
  • CHK011 Does the spec keep the proposal provider-owned rather than platform-core? [Consistency, Spec Provider Boundary / Platform Core Check]
  • CHK012 Are persistence, enums/statuses, taxonomies, interfaces, registries, DTOs, consumers, and UI frameworks answered explicitly? [Completeness, Spec Proportionality Review]
  • CHK013 Is the correct narrower path—folding the mapping into the first real consumer spec—documented? [Proportionality, Spec Spec Candidate Check]
  • CHK014 Are hard stops objectively tied to scope-changing conditions? [Measurability, Spec Final Candidate Gate]

Input Contract Quality

  • CHK015 Does the spec require the complete Spec 437 result envelope rather than the nested payload? [Clarity, Spec Input Contract]
  • CHK016 Are all required top-level envelope fields, types, and success values enumerated? [Completeness, Spec Input Contract]
  • CHK017 Are workload, nested type, shape version, compare-input marker, identity, redaction, provenance, and target sections enumerated at their exact paths? [Traceability, Spec Input Contract]
  • CHK018 Is the exact comparable shape version fixed? [Clarity, Spec Input Contract]
  • CHK019 Are Spec 437 comparable-hash recomputation and constant-time consistency comparison defined while explicitly stating that the unkeyed hash does not authenticate origin or provenance and requires trusted in-process composition? [Integrity, Spec Input Contract]
  • CHK020 Is identity anchor validation defined without permitting anchor output? [Security, Spec Input Contract]
  • CHK021 Are canonical remote-domain identity denylist rules and domain_name_is_identity=false explicit? [Security, Spec Input Contract]
  • CHK022 Must inbound routing duplicates agree with canonical material values? [Consistency, Spec Input Contract]
  • CHK023 Is invalid input exactly null, are recognized allowlisted fields distinguished from ignored unknown fields, and must every protected_values/sensitive_values entry pass exact marker-key-set validation without a new blocker/status taxonomy? [Clarity, Spec Input Contract]
  • CHK024 Are Evidence, Resource, ResourceType, OperationRun, raw/normalized input, streams, provider response, and old-renderer fallbacks prohibited? [Coverage, Spec Forbidden Input And Fallbacks]

Output Contract Quality

  • CHK025 Is the exact top-level output order and model version fixed? [Measurability, Spec Output Contract]
  • CHK026 Are fixed boundary booleans distinguished from new persisted/status truth? [Clarity, Spec Output Contract]
  • CHK027 Is identity presentation limited to the exact generic label and boolean? [Security, Spec Output Contract]
  • CHK028 Are every target section's field names, labels, types, nullability, and order defined? [Completeness, Spec target mappings]
  • CHK029 Does the spec forbid hidden metadata bags, generic pass-through, recursive output traversal, and stringification? [Completeness, Spec Functional Requirements]
  • CHK030 Are identity anchors, hashes, source, and provenance validation-only and excluded from output? [Security, Spec Common Mapping Semantics]

Count, Marker, And Determinism Quality

  • CHK031 Are configured-field, redacted-field, redacted-value, and presence semantics defined separately? [Clarity, Spec Common Mapping Semantics]
  • CHK032 Are unknown-key counting and duplicate protected/sensitive-section counting prohibited? [Edge Case, Spec Common Mapping Semantics]
  • CHK033 Is priority canonicalization defined with one output type? [Clarity, Spec Common Mapping Semantics]
  • CHK034 Are safe-enum input type, canonicalization function, accepted upstream spellings, exact token-to-output map, and rejection behavior specified? [Measurability, Spec Common Mapping Semantics]
  • CHK035 Is marker consistency fully defined across the exact key set, additional-key rejection, order independence, redacted, present, count, and state? [Completeness, Spec Common Mapping Semantics]
  • CHK036 Are key-order, unknown-key, volatile-metadata, safe-change, and protected-change expectations measurable while preserving valid envelope hashes? [Coverage, Spec Success Criteria]

Target Mapping Quality

  • CHK037 Are transportRule source sections, allowlists, safe scalars, labels, field order, and forbidden values exact? [Completeness, Spec transportRule Mapping]
  • CHK038 Does the transport contract distinguish configured fields from protected value counts? [Clarity, Spec transportRule Mapping]
  • CHK039 Are remoteDomain classification, all eight settings, groups, labels, field order, marker-only settings, and exact-domain exclusion specified? [Completeness, Spec remoteDomain Mapping]
  • CHK040 Is auto_reply_enabled the only exact safe remote-domain setting? [Security, Spec remoteDomain Mapping]
  • CHK041 Are inboundConnector material truth, routing keys, labels, field order, safe counts, and duplicate validation specified? [Completeness, Spec inboundConnector Mapping]
  • CHK042 Does the connector contract exclude exact IP/domain/host/smart-host/certificate/comment/source/routing values? [Security, Spec inboundConnector Mapping]
  • CHK043 Do all target mappings fail closed on malformed allowlisted data? [Edge Case, Spec Functional Requirements]

Truth, Surface, And Customer Boundary Quality

  • CHK044 Is data ownership N/A because the builder accepts no record/model and performs no lookup? [Consistency, Spec Spec Scope Fields]
  • CHK045 Are Evidence, Resource, ResourceType, and OperationRun immutability requirements explicit? [Completeness, Spec Evidence, Resource, And Coverage Immutability]
  • CHK046 Is in-memory model availability separated from persisted CoverageLevel::Renderable? [Clarity, Spec Evidence, Resource, And Coverage Immutability]
  • CHK047 Are ReadModel, old renderer, UI/routes, reports/Review Packs/PDF, CustomerOutputGate, certification, restore, and triggers out of scope? [Coverage, Spec Functional Requirements]
  • CHK048 Is Product Surface Impact consistently N/A with browser and Human Product Sanity rationale? [Consistency, Spec Product Surface Impact]
  • CHK049 Is OperationRun neither input, output, persistence, nor a new operation? [Consistency, Spec OperationRun UX Impact]
  • CHK050 Are migration, environment, queue, scheduler, listener, storage, asset, permission, and external-call impacts all none? [Completeness, Spec Data And Migration Impact]

Test Governance And Acceptance Quality

  • CHK051 Does the test classification follow proving purpose: Unit, focused Feature, Heavy-Governance/diff, Browser N/A? [Consistency, Spec Testing / Lane / Runtime Impact]
  • CHK052 Are array fixtures the default and database fixtures opt-in? [Cost Control, Spec Testing / Lane / Runtime Impact]
  • CHK053 Are Feature tests limited to concrete database row/attribute immutability while source, cache, filesystem, Review-Pack, report, PDF, and other side-effect absence remains explicit Heavy-Governance review? [Test Governance, tasks.md]
  • CHK054 Does planned purity proof cover database, network, filesystem, logging, cache, session, events, and queues? [Coverage, tasks.md]
  • CHK055 Are leakage, material-change, protected-value stability, and database immutability measurable? [Acceptance Quality, Spec Success Criteria]
  • CHK056 Are regression filters, Pint, diff, changed-file, and status checks named? [Completeness, Spec Testing / Lane / Runtime Impact]
  • CHK057 Are implementation-report fields and target/boundary matrices explicitly documented for this deferred close-out, with runtime work recorded as not executed in implementation-report.md? [Completeness, Spec Consumer-Owned Implementation Report Reference]
  • CHK058 Are tasks explicitly reference-only and non-executable, requiring migration into a consumer-owning spec rather than reactivation through documentation or future evidence alone? [Safety, tasks.md]
  • CHK059 Is there no product question blocking safe implementation? [BLOCKER: current operator workflow/consumer is unresolved; Spec Open Questions]

Review Outcome

  • CHK060 Technical cross-artifact findings for approval class/score, gate-resolution wording, protected/sensitive marker validation, unknown-key semantics, hash-authentication limits, compositional protected-value wording, and Feature-vs-Heavy-Governance separation were corrected in preparation files only.
  • CHK061 Review outcome is defer-or-merge-with-first-consumer, not implementation approval.
  • CHK062 Any implementation-loop invocation is prohibited while the candidate/readiness gates remain FAIL.
  • CHK063 No application code, test, migration, UI, route, or runtime behavior was changed during preparation.

Deferral Governance

  • Candidate result recorded as FAIL / Defer / 5/12.
  • Defer classification recorded in all active artifacts.
  • Implementation prohibition recorded in all active artifacts (Implementation permitted: No).
  • Missing runtime consumer and workflow owner documented.
  • Reactivation criteria documented.
  • No implementation confirmed.
  • Dirty state and diff-safety recorded in implementation-report.md.
  • Runtime scope and no-product-surface change confirmed.

Implementation Proof

  • Implemented runtime/tests: not executed.
  • Runtime implementation: not executed.
  • Runtime tests: not executed.
  • Browser checks: not run (no rendered UI surface changed).
  • Deployment impact: none.
  • Merge readiness: not merge-ready as implementation.

Preparation Result

Technical contract quality: PASS after preparation-artifact corrections. Requirements checklist: FAIL because CHK006, CHK007, and CHK059 are blocking product/constitution questions. Candidate Selection Gate: FAIL. Spec Readiness Gate: FAIL for implementation. Governance outcome: DEFERRED. Implementation outcome: NOT EXECUTED. Merge outcome: NOT APPLICABLE.

The smallest safe next action is to identify the first current internal operator consumer and fold this local transformation contract into that consumer-owning spec. No implementation behavior is proven by this checklist.