@agentskillkit/agent-skills 1.0.1 → 3.2.1

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

@@ -1,192 +0,0 @@
----
-name: coinpika-commercial-guardrails-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# 💼 CoinPika Commercial Guardrails Doctrine  
-**(Enterprise Safety · Risk · Business Continuity Law)**
-
-This doctrine defines the **commercial and enterprise guardrails**
-governing how CoinPika evolves in production.
-
-At scale,  
-**technical mistakes become business failures**.
-
-This doctrine exists to protect:
-- User trust
-- Legal exposure
-- Revenue continuity
-- Operational stability
-
----
-
-## 1. Commercial Risk Philosophy
-
-CoinPika assumes:
-
-- Long-lived systems
-- Paying users
-- Large and distributed teams
-- Regulatory and reputational exposure
-
-Therefore:
-
-- Safety outweighs speed
-- Predictability outweighs experimentation
-- Reversibility outweighs optimization
-
-A slower correct system  
-outperforms a fast broken one.
-
----
-
-## 2. Change Classification Law (MANDATORY)
-
-Every non-trivial change MUST be explicitly classified as one of:
-
-### Non-Breaking Change
-- Backward-compatible
-- Behavior-preserving
-- No user-visible risk
-
-### Breaking Change
-- Alters external behavior, APIs, or data contracts
-- Requires migration or user adaptation
-
-### Risk-Bearing Change
-- Affects correctness, trust, compliance, or revenue
-- Has non-obvious failure modes
-
-Unclassified changes are treated as  
-**HIGH RISK BY DEFAULT**.
-
----
-
-## 3. Breaking Change Law (NON-NEGOTIABLE)
-
-Breaking changes are **FORBIDDEN** unless **ALL** conditions are met:
-
-- A documented migration path exists
-- Backward compatibility is preserved during transition
-- Rollback is technically feasible
-- Blast radius is explicitly understood
-- Stakeholders are informed in advance
-
-“If it compiles” or “tests pass”  
-is NOT sufficient justification.
-
----
-
-## 4. Speculative Change Prohibition
-
-Speculative changes are **STRICTLY FORBIDDEN** in production systems.
-
-Speculative includes:
-
-- Refactors without measurable benefit
-- Architectural rewrites “for cleanliness”
-- Optimizations without proven bottlenecks
-- Technology swaps driven by novelty
-
-Every approved change MUST justify:
-
-- Why now
-- Why this approach
-- Why the risk is acceptable
-
-Curiosity is not a business strategy.
-
----
-
-## 5. Blast Radius Awareness Law
-
-Before approval, the impact of a change MUST be explicitly understood:
-
-- Who is affected
-- How many users are affected
-- What data is at risk
-- What revenue or trust is at risk
-- How rollback is performed
-
-If blast radius cannot be bounded,  
-the change MUST NOT proceed.
-
----
-
-## 6. Governance & Escalation Order
-
-When trade-offs exist between:
-
-- Safety vs speed
-- Stability vs innovation
-- Correctness vs delivery
-
-Decisions MUST defer in this order:
-
-1. CoinPika Master Constitution
-2. Architecture Doctrine
-3. Commercial Guardrails (this document)
-4. Performance Doctrine
-5. Review Checklists
-6. Agent Enforcement Protocol
-7. Developer or Agent Preference
-
-Anything lower **cannot override** anything higher.
-
----
-
-## 7. Commercial Anti-Patterns (ZERO TOLERANCE)
-
-The following are considered **commercial violations**:
-
-- Silent behavior changes
-- Breaking APIs without deprecation
-- Irreversible migrations
-- Unbounded experiments in production
-- “We’ll fix it later” reasoning
-- Launching without rollback paths
-
-If detected, changes MUST be **REVERTED IMMEDIATELY**.
-
----
-
-## 8. Enforcement Rule
-
-Any change that:
-
-- Risks user trust
-- Weakens legal or compliance posture
-- Introduces irreversible state
-- Trades correctness for delivery speed
-
-**MUST NOT BE MERGED OR DEPLOYED**.
-
-Missed deadlines are recoverable.  
-Lost trust is not.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-- Feature enthusiasm
-- Engineering curiosity
-- Short-term delivery pressure
-- Experimental ambition
-
-CoinPika protects:
-
-**Trust · Stability · Business Continuity**
-
-Because **trust is the business**.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Parent:** CoinPika Architecture Doctrine  
-**Override Permission:** NONE  

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

@@ -1,198 +0,0 @@
----
-name: coinpika-chart-data-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# 📈 CoinPika Chart Data Doctrine  
-**(Financial Truth · Historical Integrity · Visualization Law)**
-
-This doctrine defines the **non-negotiable laws** governing how
-price data is classified, stored, and visualized in CoinPika charts.
-
-Charts are **NOT visual components**.  
-Charts are **financial statements**.
-
-If chart data integrity is violated,  
-user trust is **PERMANENTLY DAMAGED**.
-
----
-
-## 1. Chart Truth Philosophy
-
-A CoinPika chart represents **historical financial truth**.
-
-It MUST be:
-
-- Accurate
-- Stable
-- Auditable
-- Non-deceptive
-
-Visual excitement MUST NEVER  
-compromise data truth.
-
----
-
-## 2. Data Classification Law (MANDATORY)
-
-All price data MUST be explicitly classified as **one** of the following.
-
-### 2.1 Historical Data
-
-Historical data is:
-
-- Immutable once written
-- Backfilled from authoritative sources
-- Fully auditable and traceable
-- Used **EXCLUSIVELY** for charts and aggregates
-
-### 2.2 Realtime Data
-
-Realtime data is:
-
-- Ephemeral and transient
-- Non-auditable
-- Display-only
-- NEVER persisted as historical truth
-
-Mixing historical and realtime data  
-is a **HARD VIOLATION**.
-
----
-
-## 3. Historical Immutability Law (NON-NEGOTIABLE)
-
-Once historical data is written:
-
-- It MUST NEVER be mutated
-- It MUST NEVER be smoothed or interpolated
-- It MUST NEVER be retroactively edited
-
-Corrections MUST occur via:
-
-- Append-only correction records
-- Explicit correction events
-
-Silent mutation is considered  
-**FINANCIAL DATA CORRUPTION**.
-
----
-
-## 4. Realtime Separation Law
-
-Realtime price data:
-
-- MUST NOT be injected into chart datasets
-- MUST NOT trigger chart re-renders
-- MUST NOT alter historical ranges, highs, or lows
-- MUST NOT affect chart scaling or aggregation
-
-Realtime data exists to inform **the present**,  
-not to rewrite **the past**.
-
----
-
-## 5. Visualization Integrity Law
-
-Charts MUST:
-
-- Render **ONLY historical data**
-- Maintain stable visual structure
-- Preserve consistent scaling per timeframe
-- Avoid jitter, flicker, or rescaling due to realtime signals
-
-If a chart visually changes due to realtime ticks,  
-the implementation is **INVALID**.
-
----
-
-## 6. Aggregation & Timeframe Law
-
-All chart aggregation MUST:
-
-- Be derived solely from historical data
-- Use deterministic, documented rules
-- Produce repeatable results for the same input
-
-Timeframe changes MUST:
-
-- Re-aggregate from historical data
-- NEVER rely on realtime ticks
-- NEVER approximate missing points
-
-Approximation for aesthetics  
-is **FORBIDDEN**.
-
----
-
-## 7. Auditability Requirement
-
-Every chart MUST be defensible under audit.
-
-A chart is INVALID if:
-
-- Any data point cannot be explained individually
-- Any value cannot be traced to a source
-- Any correction lacks historical justification
-- Any aggregation hides raw data inconsistencies
-
-If the data cannot be defended,  
-it MUST NOT be shown.
-
----
-
-## 8. Chart Anti-Patterns (ZERO TOLERANCE)
-
-The following are considered **chart violations**:
-
-- Mixing realtime ticks into historical series
-- Smoothing or interpolating missing data
-- Rewriting historical points for aesthetics
-- “Fixing” spikes without audit evidence
-- Rebuilding full chart series on every update
-- Letting animation logic influence data structure
-
-These patterns MUST be **REJECTED**, not patched.
-
----
-
-## 9. Enforcement Rule
-
-Any chart implementation that:
-
-- Misrepresents historical truth
-- Hides data inconsistencies
-- Optimizes visuals over correctness
-- Surprises an experienced analyst
-
-**MUST NOT BE MERGED OR DEPLOYED**.
-
-A misleading chart  
-is worse than no chart.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-- UI convenience
-- Animation preferences
-- Performance shortcuts that alter truth
-- “Looks better” arguments
-
-CoinPika charts exist to protect:
-
-**Truth · Auditability · User Trust**
-
-Not visual flair.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Parent:** CoinPika Architecture Doctrine  
-**Override Permission:** NONE  

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

@@ -1,165 +0,0 @@
----
-name: coinpika-frontend-mobile-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# 📱 CoinPika Frontend Mobile Doctrine  
-**(Mobile UX · Layout · Gesture Integrity Law)**
-
-This doctrine defines the **non-negotiable laws** governing how CoinPika’s
-mobile interface is structured, rendered, scrolled, and interacted with.
-
-Mobile UX is **NOT a collection of components**.  
-Mobile UX is a **system of invariants**.
-
-If mobile invariants are violated,  
-the UI may render — but the system is **BROKEN**.
-
----
-
-## 1. Mobile-First Law
-
-CoinPika is **mobile-first**, not mobile-compatible.
-
-Mobile defines:
-
-- Layout hierarchy
-- Scroll behavior
-- Gesture expectations
-- Performance constraints
-
-Desktop adapts from mobile.  
-Mobile **NEVER** adapts from desktop.
-
----
-
-## 2. Layout Invariants (NON-NEGOTIABLE)
-
-The following dimensions are **global system invariants**:
-
-- Header height: **56px**
-- TabBar height: **44px**
-- Bottom navigation height: **56px**
-
-Rules:
-
-- Values MUST be consistent across all pages
-- Values MUST NOT be overridden locally
-- Values MUST NOT be duplicated as magic numbers
-- Values MUST be defined in a single global source
-
-Changing any invariant requires  
-**system-wide architectural coordination**.
-
----
-
-## 3. Scroll Ownership Law
-
-Scroll is a **system-level responsibility**,  
-not a component-level decision.
-
-Hard rules:
-
-- The page root MUST NOT scroll
-- Swipe containers MUST NOT scroll
-- Vertical scrolling MUST exist **ONLY** inside `ScrollContent`
-- Exactly **ONE** vertical scroll container is allowed per screen
-
-Nested or competing scroll containers  
-are **CRITICAL UX VIOLATIONS**.
-
----
-
-## 4. Structural Hierarchy Law
-
-The mobile layout hierarchy is fixed:
-
-```txt
-Header (non-scrolling)
-  ↓
-TabBar (non-scrolling)
-  ↓
-Swipe / Content Container (non-scrolling)
-  ↓
-ScrollContent (ONLY scrollable layer)
-  ↓
-Bottom Navigation (non-scrolling)
-````
-
-Violating this hierarchy causes:
-
-* Sticky failures
-* Gesture conflicts
-* Scroll desynchronization
-* Platform-specific bugs (especially iOS)
-
----
-
-## 5. Gesture & Scroll Separation Law
-
-Gestures and scrolling MUST be **strictly separated**.
-
-Rules:
-
-* Gesture handling MUST live outside scroll containers
-* Scroll containers MUST NOT interpret horizontal gestures
-* Swipe logic MUST NOT depend on scroll position or state
-
-Mixing gesture logic with scrolling
-creates undefined behavior and is **FORBIDDEN**.
-
----
-
-## 6. Mobile UX Anti-Patterns (ZERO TOLERANCE)
-
-The following are considered **critical UX violations**:
-
-* Multiple vertical scroll containers
-* Scrolling headers or tab bars
-* Page-specific layout exceptions
-* Gesture logic inside scroll containers
-* Wrapper components that alter scroll context
-* Using `100vh` without subtracting system UI heights
-
-These patterns MUST be **REMOVED**, not patched.
-
----
-
-## 7. Consistency Enforcement Rule
-
-If any of the following occur:
-
-* Scroll behavior differs between pages
-* Sticky elements behave inconsistently
-* Gestures feel different across screens
-* iOS and Android behavior diverges
-
-Then the **layout system is broken**
-and MUST be fixed at the architectural level.
-
-Local fixes are **FORBIDDEN**.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-* Framework defaults
-* Component convenience
-* One-off bug fixes
-* Visual experimentation
-
-If a layout solution is easy
-but violates these laws,
-**it is the WRONG solution**.
-
----
-
-**Status:** LOCKED
-**Version:** 1.0.0
-**Parent:** CoinPika Architecture Doctrine
-**Override Permission:** NONE

package/.agent/skills/governance/rules/doctrines/frontend/coinpika-swipe-tabs-doctrine.md

@@ -1,172 +0,0 @@
----
-name: coinpika-swipe-tabs-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-frontend-mobile-doctrine
----
-
-# 👉 CoinPika Swipe Tabs Doctrine  
-**(Universal Swipe · Gesture · Navigation Law)**
-
-This doctrine defines the **single, universal swipe-tab architecture**
-used across CoinPika.
-
-Swipe is **NOT** a visual effect.  
-Swipe is a **navigation primitive**.
-
-If swipe behavior differs between pages,  
-the system is **BROKEN**.
-
----
-
-## 1. Core Intent
-
-The swipe-tabs system exists to guarantee:
-
-- Predictable gestures
-- Identical interaction across screens
-- iOS-safe scrolling behavior
-- Zero page-specific exceptions
-
-Consistency is more important than animation smoothness.
-
----
-
-## 2. Single Implementation Law (NON-NEGOTIABLE)
-
-CoinPika MUST have:
-
-- **Exactly ONE swipe implementation**
-- Shared across **ALL** pages
-- No page-specific overrides
-- No conditional gesture logic
-
-Duplicated or specialized swipe logic  
-is a **SYSTEM VIOLATION**.
-
----
-
-## 3. Swipe vs Scroll Responsibility Law
-
-Swipe and scroll are **mutually exclusive responsibilities**.
-
-Rules:
-
-- Swipe containers MUST NEVER scroll
-- Scroll containers MUST NEVER swipe
-- Swipe logic MUST NOT depend on scroll state
-- Scroll logic MUST NOT interpret horizontal gestures
-
-Violation of separation  
-creates undefined behavior.
-
----
-
-## 4. Structural Placement Law
-
-Swipe MUST live in the following structure:
-
-```txt
-Header (non-scrolling)
-  ↓
-TabBar (non-scrolling)
-  ↓
-Swipe Container (horizontal only)
-  ↓
-Tab Panel
-  ↓
-ScrollContent (vertical only)
-````
-
-Rules:
-
-* Header and TabBar MUST live OUTSIDE the swipe layer
-* Swipe container MUST NOT be transformed vertically
-* ScrollContent is the ONLY scrollable element
-
----
-
-## 5. Gesture Arbitration Law
-
-Gesture intent MUST be resolved deterministically.
-
-Rules:
-
-* Horizontal intent → swipe
-* Vertical intent → scroll
-* If vertical movement dominates → swipe MUST cancel
-* Thresholds and velocity rules MUST be global and consistent
-
-Gesture logic MUST be deterministic.
-“Heuristic” behavior is **FORBIDDEN**.
-
----
-
-## 6. Platform Consistency Law
-
-Swipe behavior MUST:
-
-* Feel identical on every page
-* Behave consistently on iOS and Android
-* Remain stable under partial or aborted gestures
-* Never break sticky layout behavior
-
-If swipe feels different anywhere,
-the implementation is **INVALID**.
-
----
-
-## 7. Forbidden Patterns (ZERO TOLERANCE)
-
-The following patterns are **STRICTLY FORBIDDEN**:
-
-* Swipe logic attached to scrollable containers
-* Page-specific gesture hacks
-* Conditional swipe enable/disable per screen
-* Mixing `transform`-based swipe with native scrolling
-* Gesture logic based on content height
-* JavaScript hacks that “almost fix” gestures
-
-If swipe feels unreliable,
-the architecture is wrong.
-
----
-
-## 8. Enforcement Rule
-
-Any swipe-related change that:
-
-* Alters gesture consistency
-* Introduces page-specific behavior
-* Breaks iOS scrolling stability
-* Requires local fixes
-
-**MUST NOT BE MERGED**.
-
-Local patches are forbidden.
-Fixes must occur at the system level.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-* Component convenience
-* Animation experiments
-* Framework gesture defaults
-* Visual polish preferences
-
-CoinPika swipe exists to protect:
-
-**Predictability · Consistency · Navigation Trust**
-
-Not visual flair.
-
----
-
-**Status:** LOCKED
-**Version:** 1.0.0
-**Parent:** CoinPika Frontend Mobile Doctrine
-**Override Permission:** NONE