@agentskillkit/agent-skills 1.0.1

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

@@ -0,0 +1,192 @@
+---
+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

@@ -0,0 +1,198 @@
+---
+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

@@ -0,0 +1,165 @@
+---
+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

@@ -0,0 +1,172 @@
+---
+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