Ana içeriğe geç

CAN-DEC-ADR-006 — Entity Control Cockpit Mimarisi ve Bounded Cockpit Foundation

Statü: ACCEPTED (Human-CEO exact-SHA, 2026-07-15; künye source 7cc8535 / blob 5533047; decision "Human-CEO kabul — Entity Control Cockpit mimarisi + bounded Cockpit-Foundation"). accepted ≠ effective ≠ implementation-authority — kabul build/merge/deploy başlatmaz (yürürlük + implementation-authority ayrı kapılar). Bu ADR, doktrin v2 (CAN-STR-DOCTRINE-001, accepted, effective_at:null) sonrası doctrine-v2-hizalı refactor ile hazırlandı (aynı canon_id, ad-değişimi; yeni-ADR YOK; full-rewrite YOK). Kat edilen yaşam-döngüsü: DRAFT→PROPOSED (upstream CAN-REQ-UCG-012 accepted) · PROPOSED→ACCEPTED (AI-CEO Katman-2 + Human-CEO exact-SHA) · sıradaki: ACCEPTED→EFFECTIVE (ayrı kapı; accepted ≠ effective).

Rol ve sınır (doktrin ⊥ bu ADR)​

DOCTRINE v2 = NEDEN + STRATEJİK INVARIANT'LAR (üst-normatif kaynak) · CAN-DEC-ADR-006 = Entity Cockpit MİMARİSİNİ o invariant'ları NASIL gerçekleştirir. Bu ADR "tüm EventInn yönetim-panellerinin mimarisi" DEĞİLDİR; görevi: Entity Control Cockpit mimarisini, bounded shared Foundation'ı ve Platform-Operator yüzeyindeki ilk güçlü IA realizasyonunu tanımlamak + gelecekteki tenant/workspace/personal management-surface'lerle semantic-uyumluluk-sınırını korumak.

Context​

Mevcut admin Filament paneli çalışıyor ama yönetilebilir değil: bilgi 182 ayrı flat-resource menüsünde dağınık; operatör tek bir varlığın gerçeğini görmek için köşe-köşe dolaşıyor (CEO gözlemi, 14 Tem — "bilgi var ama anlamlı kompozisyon yok"). User-360 kokpit-fikri bu problemi çözüyor ve aynı ihtiyaç Tenant/Venue/Supplier için de açık. Doktrin v2 bu yönü güçlendirdi: Cockpit'i açıkça bir operational decision surface (§17) olarak tanımlar, User-360'ı ilk-referans sabitler (§16), ve Management-Surface ⊥ Entity-Cockpit'i iki ayrı eksen yapar (§19).

Feasibility snapshot — app-repo @ 99695cc (14 Tem 2026; tarihsel-kanıt, sonsuz-güncel-gerçek DEĞİL — aşağıdaki 182-resource / 0-RelationManager / React-yüzey sayıları bu-SHA'ya göredir, zamanla değişebilir): her entity'nin modeli+resource'u, scoped-role şeması (Role.scope + UserRoleAssignment.tenant_id/workspace_id), ModuleVisibility global-visibility yüzeyi ve spatie/activitylog audit-omurgası shipped. Boşluk: (1) composition-katmanı yok (main'de 0 RelationManager), (2) AccessDecisionContract motoru yok (EffectiveAccessExplainer = imza-slot), (3) tenant-facing React yönetim-yüzeyi greenfield. → Desen greenfield-sistem değil; olgun katman üstünde bir kompozisyon + bilgi-mimarisi katmanıdır.

Inherited Doctrinal Constraints (doctrinal-inheritance — kopyalanmaz, bağlanır)​

Aşağıdaki stratejik-invariant'ların current-authoritative strategic source'u artık accepted CAN-STR-DOCTRINE-001 v2'dir (accepted; effective_at:null → binding/effective status AYRI — accepted ≠ effective; bir accepted-doktrin-hükmü otomatik effective-binding-rule DEĞİLDİR). Bu ADR onları tekrar-tanımlamaz; miras-alır ve yalnız mimari-sonucunu söyler (çift-source-of-truth riskini azaltır):

CAN-STR-DOCTRINE-001 (accepted v2)
├── §13  Control Plane doktrini                     〔DOC-CONTROL-PLANE〕
├── §14  Contextual Management Surfaces             〔DOC-CONTEXTUAL-MANAGEMENT〕
├── §15  Tek yönetim grameri ≠ tek UI (shared semantics ≠ shared presentation)
├── §16  Entity Control Cockpit                     〔DOC-ENTITY-COCKPIT / DOC-USER360〕
├── §17  Operational Decision Surface + Loop
├── §18  Canonical Resource ≠ Primary Navigation Item
├── §19  Management Surface ⊥ Entity Cockpit (iki eksen)
├── §21  Bounded Configurability
├── §25-27 Access Decision Contract                 〔DOC-ACCESS-CONTRACT〕
├── §28  Module Contract ≠ Cockpit Contract         〔DOC-MODULE-CONTRACT〕
├── §29  Cockpit Foundation bounded olmalıdır
├── §30-32 Truth-health / Observability / Mutation-safety
└── §34  Operational Action ≠ Verified Truth

Not: DOC-* kimlikleri reserved logical reference identifier'dır; link-resolvable oldukları tooling/materialization'da doğrulanmadan varsayılmaz (doktrin §0). Bu ADR bu invariant'ların downstream mimari-uygulayıcısıdır, tekrarı değil.

Decision question​

EventInn, uzun-yaşayan ve çok-domainli entity'leri hangi ortak Cockpit-kompozisyon mimarisiyle yönetecek; Platform-Operator yüzeyi hangi bilgi-mimarisiyle çalışacak; ve ortak Foundation gelecekteki contextual-management-surface'lerle hangi semantic-sınırlar içinde uyumlu kalacaktır?

Decision drivers​

  • Gerekçe A (production-robustness / usability): launch tek-kullanıcıyla başlamaz; "yazmışken baştan düzgün yazalım." → tek-başına shared-abstraction gerektirmez; yönetilebilir/sağlam yüzey gerektirir.
  • Gerekçe B (ortak Foundation'ı GEREKTİREN): birden fazla bilinen cockpit-entity-tipi (User/Tenant/Venue/Supplier/olası Space) şimdiden biliniyor → ortak Cockpit-Foundation kararını asıl bu destekler (çok-bilinen-tüketici).
  • Upstream UC-paketi CAN-REQ-UCG-012 (UC-ECC-001..016): bu mimari o 16 davranış-use-case'ini gerçekleştirmek için seçildi (ADR = "hangi mimariyle?"; tersine ADR'den UC icat edilmez).
  • Doktrin-inheritance: §13 (Control Plane) + §16 (Entity Cockpit, User-360-first) + §17 (operational-decision-surface) + §15/§19 (shared-semantics ≠ presentation, iki-eksen).
  • Reuse-first: 182 resource + scoped-role + audit shipped. · Anti-inflation: City360/Tag360 sprawl'ından kaçınma.

Constraints and invariants​

  1. Bounded-Foundation (big-bang değil): Foundation İNCE kurulur ve User-360 ile aynı teslimatta PROVEN olur (§29-inheritance). Sözleşme+shell+registry+action/audit-disiplini+context-modeli+navigation-ilkeleri = UPFRONT. Tüm-182-taşıma · tüm-cockpit-şimdi · tüm-section-tipini-bugün · universal-mega-framework = YASAK. Kanıt-kilidi: hiçbir contract, en az bir gerçek tüketici (User-360) tarafından egzersiz edilmeden motor olarak build edilmez; gerisi seam kalır.
  2. Composition-responsibility ⊥ component-choice: ADR section → source → visibility → actions → deep-links kompozisyon-modelini kilitler; Filament/React component-seçimini (RelationManager/Infolist/custom-page/widget) implementation'a bırakır.
  3. Surface realization boundary (legacy-ADR-038 §2.5-R1 — current-realization, semantic-invariant DEĞİL): bugünkü teknoloji-gerçeği: Platform-Operator → Filament /admin/{entity}/{id}; tenant/müşteri-yöneticisi → React/AppShell /dashboard. SEMANTIC BOUNDARY = STABLE · FRAMEWORK REALIZATION = EVOLVABLE — shared Cockpit-semantiği bu framework-seçimine bağımlı değildir; ADR salt frontend-teknoloji değişti diye supersede edilmez.
  4. No-Fake-Engine: WHY / effective-access / effective-visibility yalnız gerçek-resolver aktive olunca gösterilir. Motor-yoksa sahte-360-zekâsı YOK.
  5. Cockpit-Eligibility gate: bir entity ancak long-lived + multi-domain + lifecycle + permissions + commercial/operational-context + audit + privileged-actions + operator-decision-complexity bileşimini taşırsa cockpit kazanır. User/Tenant/Venue = güçlü aday · Supplier = muhtemel · Space = karmaşıklığa-göre · Tag/City/Lookup = HAYIR.
  6. Projection-not-copy + Action-discipline: cockpit SoT'u kopyalamaz (SoT → Projection → Section); her mutation ACTION → AUTHORIZATION → DOMAIN SERVICE → SoT → AUDIT. Doktrin §13 "tek yazım yüzeyi" korunur.
  7. Cockpit Definition ≠ Module Contract (§28-inheritance): Cockpit-Definition (bir entity'nin cockpit'i + compose ettiği section'lar) ile Module-Contract (bir modülün entitlement/permission/visibility/audit/metrics/lifecycle sözleşmesi) birbirinin yerine geçmez. Aksi halde Cockpit-Foundation, her şeyi yutan ikinci mega-platform-contract'ına dönüşür — YASAK.

Options considered​

  • A · Status-quo (182 flat büyür) → RET (yönetilemez).
  • B · Cockpit-Foundation baştan + Platform-Operator-first (User-360) + compatibility-boundary → SEÇİLDİ.
  • C · Second-consumer extraction (Müdür ilk-önerisi) → RET (çok-tüketici bilinen; Müdür geri-çekti — şeffaf).
  • D · Universal mega-framework upfront → RET (big-bang; §Constraints-1 ihlali; aşırı-geniş-okuma).

Decision​

EventInn Platform-Operator Control Plane'i cockpit-merkezli üç-katmanlı IA'ya evrilir ve bounded shared Cockpit-Foundation baştan kurulur (ince, User-360 ile kanıtlanarak). Bu üç-katman Platform-Operator / Core-Platform-Admin PRIMARY IA'sıdır — tenant-admin / workspace-manager / personal-user aynı navigation-yapısını kullanmak zorunda değildir (§15 shared-semantics ≠ shared-presentation; §Compatibility-Boundary):

EVENTINN PLATFORM-OPERATOR CONTROL PLANE (primary IA)
├── GLOBAL CONTROL CENTERS   → cross-entity global config (Plans · Entitlements · Module-Visibility · Roles · AI-Config · Security · System)
├── DOMAIN WORKBENCHES       → liste/filtre/bulk/review-queue (Users · Tenants · Venues · Spaces · Suppliers)
└── ENTITY CONTROL COCKPITS  → tek-entity contextual understanding + güvenli-aksiyon  (/admin/{entity}/{id})

Cockpit tanımı: bir sayfa-türü değil; uzun-yaşayan ve çok-domainli bir entity hakkında operatörün gerçeği-anlamasını, bağlamı-görmesini ve güvenli-aksiyon-başlatmasını sağlayan bir Control Plane composition pattern'i. Operatör-adres-şeması /admin/{entity}/{id} (/xxx360cockpit YASAK). 182 resource kaybolmaz → canonical management primitives olur; canonical-primitive olmak primary-navigation'da görünme hakkı VERMEZ (§18-inheritance; primary-nav task/domain-küratörlü).

Operational Decision Surface (§17-inheritance) — mimari sonuç: Cockpit-composition yalnız data-section aggregation için tasarlanamaz. Cockpit-Definition ve Section-composition, entity'nin durumunu, dikkat-ihtiyaçlarını, değişimi, bilinmeyenleri ve güvenli-sonraki-aksiyonu uygun olduğu ölçüde temsil edebilecek biçimde açık kalmalıdır. Bu bir semantic-capability'dir — her cockpit'te zorunlu 5-kart gibi bir UI-template DEĞİL.

Foundation sözleşmeleri (upfront, ince — her biri 1-cümle minimum-semantik):

  • Cockpit Definition: hangi entity'nin cockpit'i ve hangi section'ları compose ettiği (≠ Module-Contract).
  • Section Contract: kimlik + projection-kaynağı + visibility-koşulu + actions + deep-links (UC-007).
  • Projection Contract: authoritative-kaynağı değiştirmeden read-projection (kopya-değil; UC-002/010).
  • Action Contract: actor/capability/subject/context + authorization + canonical mutation + audit (UC-004/008). ACTION → AUDIT EVENT; ama AUDIT EVENT ≠ VERIFIED DOMAIN TRUTH (§34-inheritance) — audited-action otomatik verified-fact/evidence/learning-truth değildir (operator-correction / owner-confirmation / moderation / verification ayrı truth-class üretir).
  • Deep-Link Contract: hedef + context-korunumu + authorization (UC-005/011).
  • Context & Authority: actor/subject/context açık taşınır; implicit tenant-authority varsayılmaz (UC-006).

Not (lifecycle-disiplini): Bu ADR mimariyi SEÇER; ACCEPTED ≠ IMPLEMENTATION-AUTHORIZED ≠ MERGED ≠ DEPLOYED. Fiziksel Foundation-implementation ilgili Feature-Train / implementation-brief / code-authority üzerinden AYRICA yürür (ADR-kabulü tek-başına build-yetkisi vermez).

Karar §Constraints-1..7'ye tabidir. User-360 v1.3 = ilk referans-implementasyon (ürün-scope FROZEN; değişen yalnız implementation-architecture).

Governance / Lifecycle Gates 〔geçişler AYRI kapılardır — CAN-GOV-LCYCLE-001〕​

  • DRAFT → PROPOSED · önkoşul: upstream CAN-REQ-UCG-012 accepted olur (bu kabul-zincirinde accepted @ 2026-07-15 → önkoşul sağlandı). Doktrin-v2'nin accepted olması CAN-DEC-ADR-006'yı otomatik proposed/accepted YAPMAMIŞTI; ayrı upstream-accept + AI-CEO + Human-CEO exact-SHA ile geçildi.
  • PROPOSED → ACCEPTED · önkoşul: (a) nihai AI-CEO (Katman-2) değerlendirmesi, (b) Human-CEO exact-SHA acceptance-event (schema: accepted ⇒ approved_by + approved_at).
  • ACCEPTED → EFFECTIVE · AYRI yürürlük-kapısı. accepted ≠ effective.

Bu bölüm yalnız governance-yaşam-döngüsü önkoşullarıdır; geri-alma/supersede §Reversal'dadır.

Implementation Verification Gates (UC-ECC → Gate) 〔governance-acceptance-state DEĞİL — implementation-kanıt〕​

⚠️ ADR ACCEPTED = mimari-karar kabul; Gate-A PASS = belirli UC'lerin implementation-kanıtı. Ayrım: accepted ≠ effective ≠ implemented ≠ verified ≠ deployed. Her Feature-Train sonunda UC-acceptance matrisi çalışır: UC-ID | Scenario | Actor | Context | Preconditions | Expected | Surface | Build-SHA | Env | Automated-Evidence | Manual-Verification | Verifier | Verified-At | Result | Known-Gap.

  • Gate A — Cockpit Foundation (+ Truth-Integrity + Operational-Decision-Surface): UC-ECC-001/002/004/005/007/008/015/016 · ilk kanıt = User-360 Core Cockpit (UC-015 = truth-integrity/degraded-state doğrulaması · UC-016 = operational-decision-surface/unknown/next-safe-action doğrulaması).
  • Gate B — Composition/Relationship/Workbench-Ops: UC-ECC-003/009/011/013/014.
  • Gate C — Contextual Multi-Surface: UC-ECC-006 · gerçek ikinci surface (tenant/customer) gelince.
  • Gate D — Global Control Integration: UC-ECC-010 · gerçek effective-config/entitlement motoru gelince.
  • Gate E — Pattern Governance: UC-ECC-012 · her yeni cockpit-adayının build-kararından ÖNCE eligibility-değerlendirmesi zorunlu.

Contextual Management Compatibility Boundary 〔Management-Surface-Continuum'un DAR ve MİMARİ hali; üst-normatif sahip = doktrin §14/§19〕​

Doktrin §14 (Contextual Management Surfaces) + §19 (Management-Surface ⊥ Entity-Cockpit iki-eksen) bu sürekliliğin current-authoritative strategic source'udur (accepted; effective ayrı); bu ADR onu tekrar-tanımlamaz, yalnız mimari-uyumluluk-sınırını çizer.

İki-eksen (miras): Entity-Cockpit ekseni (User/Tenant/Venue/Supplier/Space) ⊥ Actor-Management-Surface ekseni (Platform-Operator/Tenant-Admin/Workspace-Manager/Personal-User). Etkin-UI = Actor-Surface × Entity-Cockpit × Active-Context. LOWER-AUTHORITY SURFACE ≠ SUPER-ADMIN UI MINUS HIDDEN MENUS; PERSONAL WORKSPACE ≠ TENANT; MENU VISIBILITY ≠ AUTHORIZATION.

CAN-DEC-ADR-006 ŞUNU tanımlar (DOES define):

  • shared cockpit-semantiği (entity-meaning + section-identity + projection/action-semantics + context + authority + audit-expectations);
  • projection / action / context uyumluluğu;
  • Platform-Operator yüzeyinin ilk güçlü IA realizasyonu (Control Centers → Workbenches → Cockpits);
  • gelecekteki multi-surface'lerle semantic-uyumluluk-sınırı (Foundation-sözleşmeleri o surface'leri destekleyebilecek biçimde açık kalır).

CAN-DEC-ADR-006 ŞUNU KARARLAŞTIRMAZ (does NOT define):

  • tenant-admin tam-IA'sı · workspace-manager tam-IA'sı · personal-workspace tam-IA'sı;
  • universal navigation-model · universal component-tree;
  • universal Management-Surface-Profile şeması.

Activation boundary: Foundation'ın semantic-contract'ları bu surface'leri destekleyebilecek biçimde açık kalır; ama bu hüküm tüm-surface'lerin ŞİMDİ build'ine veya universal UI-engine'e yetki VERMEZ. Exact surface-capability/navigation/actor-UX ilgili Scenario/UC/Rule/ADR/Feature-Train zincirinde doğar. Davranışsal-upstream = CAN-REQ-UCG-012 UC-ECC-006.

Evolution & Future-Proofing Guardrails 〔çoğu doktrin-miras; burada yalnız MİMARİ-uygulama〕​

Bu bölüm yeni cockpit-feature'ı ŞİMDİ build ETTİRMEZ. Üst-normatif kaynak doktrindir; bu ADR yalnız Cockpit-mimarisine düşen sonucu bağlar:

  1. Curated Primary Navigation (§18-miras): canonical-resource ≠ primary-menu-item; primary-nav kullanıcı-görevine göre küratörlenir; düşük-seviye resource SoT-yönetimini korur ama primary-nav'dan gizlenebilir.
  2. Shared semantics ≠ shared presentation (§15-miras): paylaşılan hedef = semantic-contract; presentation her shell'e/aktöre uygun. Cockpit-Foundation universal page-engine'e dönüşmez.
  3. Truth-class separation + degraded-truth/freshness/partial-failure (§30-miras): SOURCE FACT ≠ DERIVED ≠ RECOMMENDATION ≠ ACTION; recommendation ≠ mutation; bir projection-kaynağı okunamazsa gerçek-yokluk gibi gösterilmez (section-level izole).
  4. Operational observability (§31-miras): cockpit-composition opaque-blackbox olamaz; section/projection-health · action-outcomes · authorization-denials gözlemlenebilir kalır (exact-telemetry ayrı NFR).
  5. Bounded configurability (§21-miras): CODE = capability + security-ceiling · CONTROL PLANE = izin-verilen configuration · IN-CONTEXT = izin-verilen content; panel code-security-ceiling'i gevşetemez, unrestricted page-builder'a dönüşmez.
  6. Mutation-safety inheritance (§32-miras): cockpit-action'ları platform mutation-safety (idempotency/concurrency/authorization/guard/audit) politikalarını bypass eden paralel-kanal oluşturmaz.

Activation boundary: Şimdi-bağlanan: mimari-yön + yasaklar. Şimdi-build: yalnız gerçek User-360 + mevcut Feature-Train'in egzersiz ettiği yollar. Gelecekte-aktive: gerçek UC/NFR/rule + gerçek-tüketici doğunca.

Consequences​

Pozitif: yönetilebilir cockpit-merkezli Platform-Operator Control Plane · CEO/operatör-UX (tek-kompozisyon) · eligibility-gate · gün-1-hazır omurga · yüksek-reuse · gelecek-surface'lerle semantic-uyum. Bedel: User-360 PR-1'e Foundation-tohumu-eforu (net-artı; sonraki kokpitler/surface'ler ucuzlar). Etki: admin "resource-listesi" mantığıyla büyümez; Home → Workbench → Cockpit → Contextual-Action.

Risks and mitigations​

  • Foundation → mega-framework (big-bang) → §Constraints-1 (ince + User-360-proven + IN/OUT-scope).
  • ADR'nin aşırı-geniş okunması ("tüm-yönetim-mimarisi") → §Compatibility-Boundary (DOES/DOES-NOT-define açık) + scope-narrow.
  • Premature-abstraction → yalnız-User-360-egzersiz-eden kod-yolu build; gerisi seam.
  • Fake-360-zekâsı → §Constraints-4 no-fake-engine.
  • Cockpit-inflation → §Constraints-5 eligibility-gate.
  • Upstream doktrin evrim-riski: CAN-STR-DOCTRINE-001 v2 accepted, effective_at:null; ilgili §13/§16/§14 hükümleri sonradan amendment/supersession ile değişirse CAN-DEC-ADR-006 + UCG-012 etki-analiziyle yeniden değerlendirilir.

Reversal/supersession conditions 〔yalnız geri-alma/supersede〕​

  • legacy-ADR-038 / CAN-DEC-ADR-002 / Doktrin §13/§16 ile çelişki çıkarsa bu ADR revize edilir (onlar değil).
  • Component-seçimini implementation dayatırsa = yanlış-okuma; §Constraints-2 geçerli.
  • Cockpit-Foundation kanıtlanamaz/anti-değer üretirse → ADR revize veya supersede (yeni-SHA + yeni gerekçe).
  • Framework-realization (Filament/React) değişimi tek-başına supersede-sebebi DEĞİLDİR (§Constraints-3: semantic-boundary stabil, framework evolvable).

Traceability​

  • Governed-by: CAN-GOV-UCDEP-001.
  • Upstream: CAN-REQ-UCG-012 (UC-ECC-001..016; accepted @ 2026-07-15 — DRAFT→PROPOSED önkoşulu sağlandı).
  • Related: CAN-STR-DOCTRINE-001 (accepted v2; §13/§14/§15/§16/§17/§18/§19/§21/§25-27/§28/§29/§30-32/§34) · CAN-DEC-ADR-002 (identity) · CAN-DEC-ADR-003 (decision-context) · CAN-DEC-ADR-005 (tasarım-yüzey).
  • Downstream: — (accept sonrası cockpit implementation-brief'leri + entity-özel feature-spec'ler).
  • Legacy: legacy-ADR-038 §2.5-R1 (surface-boundary = current-realization).

Evidence plan (architectural-decision-evidence ⊥ implementation-evidence — accepted ≠ implemented ≠ verified)​

Architectural-decision-evidence (bu ADR'nin KABULÜ için): feasibility-snapshot (@99695cc, tarihsel) · doctrine-v2-alignment · AI-CEO Katman-2 review · Human-CEO exact-SHA decision. (Draft: evidence_status: none — normatif tasarım-kararı, kod-kanıtı değil.) Implementation-evidence (kabul-SONRASI, AYRI Feature-Train / implementation-brief / code-authority): User-360 Foundation-contract-usage · build-SHA · canlı-site live-verification · UC-acceptance-matrix (her cockpit: Foundation-contract-uyumu + 11-invariant + UC-ECC-001..016 + surface-boundary + action→audit zinciri). Bu implementation-evidence ADR-kabulünün ÖNKOŞULU DEĞİLDİR.

Karar Çekirdeği (DECIDES / DOES NOT DECIDE)​

DOCTRINE v2  →  GENERAL COCKPIT UCs (CAN-REQ-UCG-012)  →  CAN-DEC-ADR-006

CAN-DEC-ADR-006 DECIDES:
1. Entity Control Cockpit mimarisi
2. Bounded Cockpit Foundation
3. Platform-Operator IA: Control Centers → Domain Workbenches → Entity Cockpits
4. Shared semantic contracts (Cockpit/Section/Projection/Action/Deep-Link/Context&Authority)
5. Contextual Management Compatibility Boundary (semantic-uyumluluk sınırı)
6. Cockpit eligibility
7. Safe action / projection / deep-link disiplini

CAN-DEC-ADR-006 DOES NOT DECIDE:
- tüm tenant-admin UX / workspace-manager UX / personal-workspace UX
- universal UI-engine / universal navigation
- full Access-Engine / full Entitlement-Engine
- her cockpit'in implementasyonu

Özet: Doktrin v2 = "neden + hangi stratejik sınırlar"; CAN-DEC-ADR-006 = "bu Cockpit sistemini mimari olarak nasıl kuruyoruz" — daha geniş değil, daha doğru ve daha uzun-ömürlü.