commit & push

[moonrager13]

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.
• Should specify least privileged permissions for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • creator: Name of the organization/user producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[fisallllll280-code]

بناءً على الملفات الحالية، والمراجعات السابقة، فإن الفهرس الأدق يجب أن يكون فهرسًا معماريًا (Architecture Index) وليس مجرد شجرة مجلدات. الملفات تؤكد أن المشروع يتمحور حول Runtime-first Architecture مع فصل واضح للنواة، العقود، المجالات، والبنية التحتية، وأن النواة المقصودة هي Distributed Sovereign Runtime وليست تطبيق Backend تقليدي. fileciteturn0file0L3-L112 fileciteturn0file2L1-L71

V-System/
│
├── 0000 Foundation
│   ├── Vision
│   ├── Principles
│   ├── Philosophy
│   ├── Terminology
│   ├── Standards
│   └── Architecture Decision Records (ADR)
│
├── 0100 Runtime
│   ├── Kernel
│   │   ├── Bootstrap
│   │   ├── Lifecycle
│   │   ├── Scheduler
│   │   ├── Runtime Context
│   │   ├── Health
│   │   └── Orchestrator
│   │
│   ├── Execution
│   ├── Decision Runtime
│   ├── Command Pipeline
│   ├── Event Pipeline
│   ├── Commit Engine
│   ├── State Machine
│   ├── Replay Engine
│   ├── Snapshot Engine
│   ├── Recovery
│   ├── Resilience
│   ├── Synchronization
│   ├── Runtime Manifest
│   └── Runtime Configuration
│
├── 0200 Decision Fabric
│   ├── Decision Model
│   ├── Arbitration
│   ├── Priorities
│   ├── Temporal Evaluation
│   ├── Policy Evaluation
│   ├── Decision Context
│   ├── Decision History
│   └── Decision Metrics
│
├── 0300 Event Fabric
│   ├── Event Model
│   ├── Event Bus
│   ├── Event Store
│   ├── Event Router
│   ├── Event Dispatcher
│   ├── Event Replay
│   ├── Event Stream
│   ├── Event Persistence
│   └── Event Versioning
│
├── 0400 Trust Fabric
│   ├── Trust Engine
│   ├── Trust Score
│   ├── Reputation
│   ├── Trust Policies
│   ├── Trust Snapshot
│   ├── Byzantine Detection
│   ├── Latency Penalty
│   └── Trust Ledger
│
├── 0500 Consensus Fabric
│   ├── Consensus Engine
│   ├── Quorum
│   ├── Voting
│   ├── Trust Weighted Consensus
│   ├── Conflict Resolution
│   ├── Leader Election
│   ├── Replication
│   └── Distributed Coordination
│
├── 0600 State Fabric
│   ├── State Manager
│   ├── State Store
│   ├── State Projection
│   ├── Snapshot
│   ├── Versioning
│   ├── Rollback
│   ├── Restore
│   └── Consistency
│
├── 0700 Ledger Fabric
│   ├── Immutable Ledger
│   ├── Commit Records
│   ├── Audit Trail
│   ├── Operational History
│   ├── Integrity
│   └── Verification
│
├── 0800 Contracts
│   ├── Events
│   ├── Decisions
│   ├── Commits
│   ├── Trust
│   ├── State
│   ├── Runtime
│   ├── APIs
│   └── Schemas
│
├── 0900 Infrastructure
│   ├── Messaging
│   ├── Storage
│   ├── Cache
│   ├── Database
│   ├── Object Storage
│   ├── Networking
│   ├── Service Discovery
│   └── Secrets
│
├── 1000 Distributed Runtime
│   ├── Nodes
│   ├── Regions
│   ├── Cluster
│   ├── Replication
│   ├── Failover
│   ├── Federation
│   ├── Multi Region
│   └── Edge Runtime
│
├── 1100 Observability
│   ├── Dashboard
│   ├── Metrics
│   ├── Logs
│   ├── Traces
│   ├── Runtime Stream
│   ├── Alerts
│   ├── Timeline
│   └── Monitoring
│
├── 1200 Security
│   ├── Identity
│   ├── Authentication
│   ├── Authorization
│   ├── Encryption
│   ├── Policies
│   ├── Compliance
│   └── Audit
│
├── 1300 Storage
│   ├── Event Store
│   ├── Snapshot Store
│   ├── Ledger Store
│   ├── Object Store
│   └── Archives
│
├── 1400 Domains
│   ├── Banking
│   ├── AI Agents
│   ├── Logistics
│   ├── Governance
│   ├── Healthcare
│   ├── Manufacturing
│   └── Custom Domains
│
├── 1500 SDK
│   ├── Python
│   ├── Rust
│   ├── Go
│   ├── Java
│   ├── TypeScript
│   └── C#
│
├── 1600 API
│   ├── REST
│   ├── gRPC
│   ├── GraphQL
│   ├── Streaming
│   └── Gateway
│
├── 1700 Applications
│   ├── Dashboard
│   ├── CLI
│   ├── Admin
│   ├── Mobile
│   └── Desktop
│
├── 1800 Simulations
│   ├── Replay
│   ├── Load Testing
│   ├── Chaos
│   ├── AI Simulation
│   └── Benchmark
│
├── 1900 Deployment
│   ├── Docker
│   ├── Kubernetes
│   ├── AWS
│   ├── Azure
│   ├── GCP
│   ├── Edge
│   └── CI/CD
│
├── 2000 Documentation
│   ├── Architecture
│   ├── Runtime
│   ├── APIs
│   ├── ADR
│   ├── Tutorials
│   ├── Guides
│   └── Specifications
│
└── 9999 Future Fabrics
    ├── Evolution Fabric
    ├── Intelligence Fabric
    ├── Autonomous Fabric
    ├── Quantum Fabric
    ├── Cognitive Fabric
    ├── Reality Fabric
    └── Unknown Fabric

ملاحظات معمارية

هذا الفهرس يطابق الاتجاه الذي ظهر في الملفات:

• Runtime هو النواة وليس Service. fileciteturn0file1L26-L61
• Infrastructure منفصلة عن الـ Runtime، ويُنقل إليها Event Bus. fileciteturn0file1L28-L43
• Observability طبقة مستقلة تشمل الـ Dashboard والبث الحي. fileciteturn0file0L71-L104 fileciteturn0file1L45-L50
• Contracts هي نقطة الاتصال الوحيدة بين المكونات. fileciteturn0file1L60-L84
• Domains معزولة عن النواة ويمكن توسيعها دون تعديل الـ Runtime. fileciteturn0file1L52-L58
• الترتيب المقترح لبناء النظام يبدأ بـ Kernel → Contracts → Replay → Consensus → State قبل أي ميزات أو تطبيقات. fileciteturn0file3L3-L64

بهذا يصبح الفهرس أقرب إلى Ontology معمارية تغطي جميع طبقات V-System، وليس مجرد تنظيم للمجلدات.

[fisallllll280-code]

المشكلة المذكورة هي Bug في نظام invalidation/cache وليست في إعادة التصدير نفسها.

التغيير المطلوب: جعل أدوات البناء تعرف أن ملفات الأنواع الجديدة (leaf type files) أصبحت مصادر رسمية لعقود SDK.

التنفيذ المقترح:

1. تعديل scripts/prepare-extension-package-boundary-artifacts.mjs

ابحث عن:

const PLUGIN_SDK_TYPE_INPUTS = [
"src/plugins/types.ts",
];

غيّرها إلى شيء يعتمد على كل ملفات الأنواع:

const PLUGIN_SDK_TYPE_INPUTS = [
"src/plugins/types.ts",
"src/plugins/*.types.ts",
];

أو الأفضل إذا السكربت لا يدعم glob:

const PLUGIN_SDK_TYPE_INPUTS = [
"src/plugins/types.ts",
"src/plugins/provider-plugin.types.ts",
"src/plugins/*.types.ts",
];

⸻

2. تحديث CI cache key

ابحث في ملفات CI مثل:

.github/workflows/*.yml

عن:

src/plugins/types.ts

مثلاً:

hashFiles('src/plugins/types.ts')

استبدله:

hashFiles('src/plugins/types.ts', 'src/plugins/*.types.ts')

⸻

3. إضافة اختبار يمنع رجوع المشكلة

أضف test أو check:

assert(
PLUGIN_SDK_TYPE_INPUTS.some(
input => input.includes("*.types.ts")
),
"Plugin SDK type invalidation must include split type files"
);

⸻

4. Commit مقترح

git add scripts/prepare-extension-package-boundary-artifacts.mjs .github/workflows
git commit -m "fix: track split plugin SDK type files in DTS invalidation"
git push

النتيجة بعد الإصلاح:

• أي تعديل في:
  • src/plugins/provider-plugin.types.ts
  • src/plugins/*.types.ts

سيجبر:

• إعادة توليد openclaw/plugin-sdk
• تحديث .boundary-dts.stamp
• كسر cache القديم

وبكذا ينتهي خطر خروج SDK declarations قديمة.

[fisallllll280-code]

هذا النوع من الوثائق يستحق أن يُكتب كـ RFC (Request for Comments) أو Software Architecture Specification (SAS)، وليس كملاحظات تصميم. بهذه الصيغة سيكون مناسبًا لمستودع GitHub، أو مراجعة هندسية، أو حتى كورقة مرجعية.

أقترح أن تكون وثيقة VX بهذا المستوى من الاحتراف:

⸻

VAIXLNS Architecture Specification

VX Root Kernel

Document ID: VAIXLNS-SPEC-002-VX
Title: VX Root Kernel Specification
Status: Ratified
Version: 1.0.0
Layer: Foundation Layer (L0)
Classification: Core Kernel Specification

⸻

1. Abstract

تمثل VX النواة الجذرية (Root Kernel) لمنصة VAIXLNS، وهي أعلى مكوّن تنفيذي في طبقة Foundation.

تتمثل مسؤولية VX في إنشاء بيئة التشغيل، تهيئة دورة حياة النظام، والتحقق من جاهزية البنية الأساسية قبل السماح لأي مكوّن آخر بالعمل.

لا تحتوي VX على أي منطق أعمال (Business Logic)، ولا تعرف أي تفاصيل عن المجال المالي، أو الذكاء الاصطناعي، أو التداول، أو الحوكمة.

⸻

2. Design Philosophy

تعتمد VX على المبادئ التالية:

• Deterministic Bootstrapping
• Specification Before Implementation
• Lifecycle Ownership
• Zero Business Knowledge
• Immutable Initialization
• Dependency Isolation
• Security by Design
• Fail Fast Principle

⸻

3. Objectives

تلتزم VX بتحقيق الأهداف التالية:

• إنشاء بيئة تشغيل حتمية.
• إدارة دورة حياة النظام.
• تسجيل المكونات.
• تحميل التكوين.
• التحقق من سلامة الإقلاع.
• منع بدء التشغيل عند وجود أخطاء حرجة.

⸻

4. Out of Scope

يحظر على VX تنفيذ أي مما يلي:

• اتخاذ قرارات.
• تنفيذ التداول.
• حساب المؤشرات.
• إدارة المخاطر.
• الوصول للأسواق.
• تشغيل الذكاء الاصطناعي.
• تعديل Ledger.
• تطبيق السياسات.

⸻

5. Architectural Responsibilities

تشمل مسؤوليات VX:

1. Bootstrap Management
2. Runtime Initialization
3. Configuration Loading
4. Component Registration
5. Kernel Lifecycle
6. Startup Validation
7. Graceful Shutdown
8. Health Initialization

⸻

6. Lifecycle Model

Created
│
▼
Configuration Loading
│
▼
Bootstrap
│
▼
Component Registration
│
▼
Initialization Validation
│
▼
Kernel Ready
│
▼
Running
│
▼
Shutdown Requested
│
▼
Graceful Shutdown
│
▼
Stopped

⸻

7. State Machine

State Description
Uninitialized لم يبدأ النظام
Initializing تهيئة النواة
Ready جاهز للتشغيل
Running النظام يعمل
Stopping إيقاف آمن
Stopped توقف كامل
Failed فشل غير قابل للاستمرار

⸻

8. Public Interfaces

يوفر VX الواجهات المفاهيمية التالية:

• Initialize()
• RegisterComponent()
• ResolveConfiguration()
• Start()
• Shutdown()
• ReportHealth()

لا يسمح بأي واجهات خاصة بالتداول أو الذكاء أو الحوكمة.

⸻

9. Dependency Contract

Depends On

• Runtime Environment
• Configuration Provider
• System Resources

Must Never Depend On

• XV
• V
• VN
• NV
• VV
• XX
• LL
• NN
• SS
• II
• VIX
• LNS

⸻

10. Authority Boundary

يسمح لـ VX فقط بـ:

• إنشاء النظام.
• تسجيل المكونات.
• إدارة دورة الحياة.

ولا يمتلك أي صلاحية تشغيلية داخل المجال المالي.

⸻

11. Security Constraints

تلتزم VX بما يلي:

• عدم الوصول إلى الأسواق.
• عدم تنفيذ أوامر.
• عدم تعديل السياسات.
• عدم تعديل البيانات المالية.
• عدم تجاوز عقود الوكلاء.
• نشر أحداث Lifecycle فقط.

⸻

12. Runtime Invariants

يجب أن تبقى الشروط التالية صحيحة دائماً:

• جميع المكونات مسجلة قبل التشغيل.
• يمنع التسجيل بعد Ready.
• يمنع تغيير Lifecycle.
• يمنع تجاوز Bootstrap.
• يمنع إعادة التهيئة أثناء التشغيل.

⸻

13. Failure Contract

في حال حدوث خطأ حرج:

1. إيقاف عملية الإقلاع.
2. نشر KernelFailure.
3. رفض الانتقال إلى Running.
4. تحرير الموارد.
5. إنهاء التشغيل بصورة آمنة.

⸻

14. Extension Model

يمكن توسيع VX عبر:

• Providers
• Extensions
• Plugins
• Boot Modules

دون تعديل النواة.

⸻

15. Performance Requirements

• Boot Time قابل للقياس.
• Startup Deterministic.
• Registration Order ثابت.
• Startup Repeatable.

⸻

16. Acceptance Criteria

تعتبر VX مطابقة للمواصفة إذا:

• نجح الإقلاع.
• سجلت جميع المكونات.
• لم تُسجل أي مكونات بعد Ready.
• لم يحدث أي Dependency Leak.
• كانت جميع انتقالات الحالة صحيحة.

⸻

17. Architectural Laws

Law VX-01

VX owns the lifecycle.

Law VX-02

VX shall contain no business logic.

Law VX-03

VX shall never depend on higher architectural layers.

Law VX-04

Every component shall be initialized through VX.

Law VX-05

Initialization shall be deterministic.

⸻

18. Compliance Matrix

Requirement Status
Deterministic Lifecycle Required
Zero Business Logic Required
Security Isolation Required
Immutable Initialization Required
Component Registration Required
Graceful Shutdown Required

⸻

19. Revision History

Version Status Notes
1.0.0 Ratified Initial global specification

⸻

التقييم المعماري

بهذا المستوى، لا تصبح الوثيقة مجرد README، بل Software Architecture Specification (SAS) قابلة للتدقيق. وهي مناسبة كمستند رسمي داخل:

docs/
└── architecture/
├── 01-core-architecture-charter.md
├── 02-vx-root-kernel.md
├── 03-xv-kernel-coordinator.md
├── 04-v-governance-kernel.md
├── 05-vn-verification-network.md
├── 06-nv-normalization-validation.md
├── 07-vv-verification-agent.md
├── 08-xx-execution-agent.md
├── 09-ll-immutable-ledger.md
├── 10-nn-causal-model-service.md
├── 11-ss-strategy-service.md
├── 12-ii-intelligence-agent.md
├── 13-vix-decision-orchestrator.md
└── 14-lns-specification-layer.md

بهذا الهيكل تصبح مواصفات VAIXLNS أقرب إلى الوثائق المرجعية التي تُستخدم في المشاريع المؤسسية والأنظمة الحرجة، حيث يُعد كل ملف مواصفة مستقلة ذات هوية وإصدار وقوانين واضحة، وليس مجرد شرح للمكونات.