@agentskillkit/agent-skills 1.0.1 → 3.2.2

package/.agent/skills/governance/rules/constitution/coinpika-master-constitution.md

@@ -1,206 +0,0 @@
----
-name: coinpika-master-constitution
-version: 1.0.0
-status: LOCKED
-authority: SUPREME
----
-
-# 👑 CoinPika Master Constitution  
-**(Supreme Engineering Constitution)**
-
-This document is the **highest authority** governing how CoinPika is designed,
-built, reviewed, scaled, and evolved.
-
-It represents the standards of **world-class, long-lived systems**
-(Bloomberg, Google, Apple, TradingView).
-
-If this Constitution is violated,  
-the solution is **INVALID — even if it works**.
-
----
-
-## 1. Constitutional Scope
-
-This Constitution governs:
-
-- System architecture
-- Data integrity and truth
-- Product correctness
-- Performance philosophy
-- Review authority
-- AI agent behavior and learning
-
-It explicitly does **NOT** optimize for:
-
-- Speed of delivery
-- Framework fashion
-- Short-term convenience
-- Developer comfort
-
-No lower-level document may override this Constitution.
-
----
-
-## 2. Prime Directives (IMMUTABLE)
-
-These directives are **absolute**.
-
-They cannot be overridden by:
-- Preference
-- Urgency
-- Learning
-- AI suggestion
-- User request
-
-1. **Correctness > Convenience**
-2. **Trust > Speed**
-3. **Architecture > Trends**
-4. **Predictability > Cleverness**
-5. **Explicit trade-offs only**
-
-Any solution violating a Prime Directive  
-is invalid by definition.
-
----
-
-## 3. System Laws (NON-NEGOTIABLE)
-
-### Law 1 — Truth Ownership
-The backend is the **single source of truth**.
-
-If the frontend can alter financial meaning,  
-the system is architecturally broken.
-
----
-
-### Law 2 — Historical Integrity
-Historical data is **immutable**.
-
-Corrections occur via **append-only mechanisms**,  
-never mutation or replacement.
-
----
-
-### Law 3 — Realtime Ephemerality
-Realtime data is transient and display-only.
-
-It MUST NOT:
-- Be persisted as history
-- Affect aggregates
-- Contaminate charts
-
----
-
-### Law 4 — Chart Truthfulness
-Charts represent **historical financial truth**,  
-not realtime excitement.
-
-Realtime ticks MUST NEVER be injected into charts.
-
----
-
-## 4. Controlled Self-Improvement Doctrine
-
-CoinPika may improve **reasoning**,  
-but MUST NEVER modify **laws**.
-
-### Learning Precedence
-Learning is strictly **subordinate** to this Constitution.
-
-If a learned behavior conflicts with any
-Prime Directive or System Law,  
-the learning MUST be rejected and rolled back.
-
----
-
-### Learning Scope
-The system MAY learn:
-- Better reasoning patterns
-- Improved decision heuristics
-- More accurate architectural judgment
-
-The system MUST NEVER learn:
-- Code style
-- Naming conventions
-- Temporary workarounds
-- Project-specific hacks
-- Exceptions to laws
-
----
-
-### Learning Activation
-Learning is triggered ONLY when:
-- A previous agent decision is explicitly corrected
-- A demonstrably superior approach is provided
-- Architectural reasoning is overridden by the user
-
-Code alone does NOT trigger learning.
-
----
-
-## 5. Decision Precedence Order
-
-When conflicts arise, decisions are resolved in this order:
-
-1. 👑 **CoinPika Master Constitution**
-2. Architecture & System Doctrines
-3. Commercial Guardrails
-4. Performance Doctrine
-5. Review Checklists
-6. Agent Enforcement Protocol
-7. Developer or Agent Preference
-
-Anything lower **cannot override** anything higher.  
-There are **NO exceptions**.
-
----
-
-## 6. Enforcement Rule
-
-A decision is **invalid** if it:
-
-- Cannot be justified using this Constitution
-- Introduces implicit or hidden trade-offs
-- Surprises an experienced engineer
-- Requires “special context” to be safe
-
-Systems must be safe by design,  
-not safe by memory.
-
----
-
-## 7. AI Authority Limits
-
-AI agents:
-
-- Are proposal-only
-- Have zero trust by default
-- Cannot approve, merge, or override laws
-- Must cite applicable doctrines
-
-AI usefulness NEVER overrides system safety.
-
----
-
-## Final Authority
-
-This Constitution overrides:
-
-- All other doctrines
-- All skills
-- All frameworks
-- All tools
-- All preferences
-- “It works” arguments
-
-CoinPika optimizes for:
-
-**Long-term trust · Correctness · Durability**
-
-Not short-term velocity.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Override Permission:** NONE  

package/.agent/skills/governance/rules/doctrines/architecture/coinpika-architecture-doctrine.md

@@ -1,184 +0,0 @@
----
-name: coinpika-architecture-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-master-constitution
----
-
-# 🏛️ CoinPika Architecture Doctrine  
-**(System Architecture & Boundary Law)**
-
-This doctrine defines the **architectural laws** governing how CoinPika is
-structured, scaled, and evolved.
-
-Architecture exists to:
-- Prevent silent data corruption
-- Prevent system-wide inconsistency
-- Prevent “working but wrong” systems
-
-If architecture is violated,  
-the system may appear functional — **but it is already broken**.
-
----
-
-## 1. Architectural Intent
-
-CoinPika is a **data-trust platform**, not a feature-driven application.
-
-The architecture prioritizes:
-- Correctness over speed
-- Predictability over flexibility
-- Explicit ownership over convenience
-
-Any design that obscures ownership  
-is architecturally invalid.
-
----
-
-## 2. System Boundary Law (NON-NEGOTIABLE)
-
-The system is divided into **strict, enforceable boundaries**:
-
-### Backend
-- Source of truth
-- Data ingestion and normalization
-- Persistence and aggregation
-- Cost, rate-limit, and integrity control
-
-### Frontend
-- Rendering and presentation
-- User interaction
-- Visual state only
-- NO truth ownership
-
-### External Systems
-- Untrusted dependencies
-- Volatile availability
-- Never authoritative
-
-Crossing these boundaries **without mediation**
-is an architectural violation.
-
----
-
-## 3. Single Source of Truth Law
-
-Every piece of **critical data** MUST have:
-
-- One authoritative owner
-- One normalization path
-- One persistence strategy
-
-Multiple truths are worse than missing data.
-
-Client-side arbitration of truth  
-is strictly forbidden.
-
----
-
----
-
-## 4. Dependency Direction Law
-
-Dependencies MUST flow **inward** toward the core:
-External Services
-        ↓
-     Backend
-        ↓
-     Frontend
-
-The frontend MUST NEVER:
-- Depend directly on external APIs (production)
-- Reconstruct backend meaning
-- Patch missing data
-
-If the frontend can “fix” backend data,  
-the architecture is invalid.
-
----
-
-## 5. Scalability Invariants
-
-Scalability is a **first-order architectural property**,  
-not a later optimization.
-
-The system MUST:
-- Scale users independently of external dependencies
-- Absorb traffic spikes without amplification
-- Fail gracefully under partial outages
-- Preserve data correctness under load
-
-If scaling requires architectural rewrite,  
-the original design is invalid.
-
----
-
-## 6. Evolution Without Erosion Law
-
-Architecture may evolve,  
-but MUST NOT erode.
-
-### Allowed Evolution
-- Additive extensions
-- Explicit migrations
-- Backward-compatible improvements
-
-### Forbidden Evolution
-- Layering exceptions
-- Feature-driven shortcuts
-- “Temporary” architecture without removal plans
-- Accumulating special cases
-
-Erosion is failure by accumulation.
-
----
-
-## 7. Architectural Anti-Patterns (ZERO TOLERANCE)
-
-The following are considered **architectural violations**:
-
-- Blurred or shared data ownership
-- Feature-specific architecture
-- Client-side truth decisions
-- Hidden coupling between layers
-- Implicit contracts
-- Architecture that relies on “tribal knowledge”
-
-These patterns must be **rejected**, not mitigated.
-
----
-
-## 8. Enforcement Rule
-
-Any design or implementation that:
-
-- Violates a system boundary
-- Obscures data ownership
-- Introduces implicit coupling
-- Requires special context to be safe
-
-**MUST be rejected**, regardless of delivery pressure.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-- Feature requirements
-- Framework defaults
-- Tooling constraints
-- Short-term optimization goals
-
-CoinPika architecture exists to protect:
-
-**Long-term trust · Correctness · Scalability**
-
-Not developer convenience.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Parent:** CoinPika Master Constitution  
-**Override Permission:** NONE  

package/.agent/skills/governance/rules/doctrines/backend/coinpika-backend-data-engine-doctrine.md

@@ -1,214 +0,0 @@
----
-name: coinpika-backend-data-engine-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# 🧱 CoinPika Backend Data Engine Doctrine  
-**(Data Truth · Ingestion · Persistence Law)**
-
-This doctrine defines the **backend data engine laws** governing how CoinPika
-ingests, normalizes, persists, caches, and serves data.
-
-The backend is **NOT** an API relay.  
-The backend is a **data truth engine**.
-
-If backend authority is bypassed,  
-the system is **COMPROMISED** — even if it appears functional.
-
----
-
-## 1. Data Engine Purpose
-
-The backend exists to protect:
-
-- Data correctness
-- Historical integrity
-- Cost and rate limits
-- Deterministic behavior
-- Long-term scalability
-
-The backend is the **only layer** allowed to interpret external data.
-
----
-
-## 2. Truth Ownership Law (NON-NEGOTIABLE)
-
-The backend is the **single authoritative owner** of:
-
-- External data ingestion
-- Normalization and aggregation
-- Validation and correction
-- Persistence and storage
-- Cache and freshness policy
-
-The frontend MUST NEVER:
-
-- Call third-party APIs directly (production)
-- Normalize or aggregate raw data
-- Guess, synthesize, or “fix” missing values
-- Persist authoritative data
-
-Any violation is a **DATA INTEGRITY BREACH**.
-
----
-
-## 3. External Dependency Isolation Law
-
-All third-party data sources MUST be:
-
-- Isolated behind backend APIs
-- Rate-limited centrally
-- Cached and buffered
-- Replaceable without frontend changes
-
-External systems are treated as:
-
-- Unreliable
-- Rate-limited
-- Non-authoritative
-
-They are **inputs**, never system components.
-
----
-
-## 4. Ingestion Taxonomy Law
-
-All ingestion MUST be explicitly classified.  
-Unclassified ingestion is **FORBIDDEN**.
-
-### 4.1 Backfill Ingestion
-
-- One-time or rare execution
-- Writes immutable historical data
-- Fully auditable and traceable
-- NEVER overwritten
-
-### 4.2 Incremental / Scheduled Ingestion
-
-- Periodic execution
-- Append-only or deterministic overwrite
-- Idempotent by design
-- Safe to retry
-
-### 4.3 Realtime Ingestion
-
-- Ephemeral and transient
-- MUST NEVER be persisted as history
-- Used only for live indicators
-- Discarded after use
-
-Mixing ingestion categories  
-is a **HARD VIOLATION**.
-
----
-
-## 5. Persistence & Immutability Law
-
-Historical data:
-
-- MUST be immutable once written
-- MUST NOT be smoothed or interpolated
-- MUST NOT be retroactively edited
-
-Corrections MUST occur via:
-
-- Append-only records
-- Explicit correction events
-
-Silent mutation is considered **DATA CORRUPTION**.
-
----
-
-## 6. Caching & Cost Control Law
-
-Caching is **NOT** an optimization.  
-Caching is a **cost, stability, and safety mechanism**.
-
-The backend MUST:
-
-- Serve cached data by default
-- Refresh data asynchronously
-- Prevent cache stampedes
-- Absorb traffic spikes without amplification
-
-Freshness MUST NEVER:
-
-- Block responses
-- Amplify third-party API usage
-- Compromise system stability
-
----
-
-## 7. Scaling Invariant
-
-External API usage MUST NOT scale with user count.
-
-The correct model is:
-
-```txt
-External APIs
-      ↓
-   Backend
-      ↓
-Unlimited Clients
-````
-
-If user growth increases third-party calls,
-the architecture is **INVALID**.
-
----
-
-## 8. Backend Anti-Patterns (ZERO TOLERANCE)
-
-The following are considered **backend violations**:
-
-* Client-side third-party API calls
-* Treating backend as a thin proxy
-* Persisting realtime data as history
-* Per-request external fetches
-* Silent retries hiding corruption
-* Backend logic conditional on frontend behavior
-
-These patterns MUST be **REJECTED**, not patched.
-
----
-
-## 9. Enforcement Rule
-
-Any backend implementation that:
-
-* Blurs data ownership
-* Leaks external dependency semantics
-* Requires frontend fixes to be “correct”
-* Introduces hidden coupling
-
-**MUST NOT BE MERGED**.
-
-Correctness overrides convenience.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-* Performance shortcuts
-* Framework defaults
-* “Temporary” backend logic
-* Cost-driven compromises that weaken truth
-
-The backend exists to protect:
-
-**Truth · Integrity · Scalability**
-
-Not developer speed.
-
----
-
-**Status:** LOCKED
-**Version:** 1.0.0
-**Parent:** CoinPika Architecture Doctrine
-**Override Permission:** NONE