@agentskillkit/agent-skills 1.0.1

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

@@ -0,0 +1,188 @@
+---
+name: coinpika-learning-engine-doctrine
+version: 1.0.0
+status: LOCKED
+authority: CONSTITUTIONAL
+parent: coinpika-architecture-doctrine
+---
+
+# 🧠 CoinPika Learning Engine Doctrine  
+**(Controlled Learning · Reasoning Integrity Law)**
+
+This doctrine defines how CoinPika is **allowed to learn and improve over time**
+without violating architectural, data, or trust invariants.
+
+Learning is power.  
+Uncontrolled learning is **SYSTEM FAILURE**.
+
+CoinPika learns to become **more correct**,  
+not more flexible.
+
+---
+
+## 1. Learning Philosophy
+
+CoinPika does **NOT** learn code.  
+CoinPika does **NOT** learn implementation details.
+
+CoinPika learns:
+
+- Reasoning patterns
+- Decision heuristics
+- Architectural judgment
+
+The goal of learning is:
+
+- Increased correctness
+- Increased predictability
+- Reduced future mistakes
+
+Novelty and cleverness are **NOT goals**.
+
+---
+
+## 2. Learning Authority Law (NON-NEGOTIABLE)
+
+All learning is **strictly subordinate** to:
+
+1. CoinPika Master Constitution
+2. Architecture Doctrine
+3. System Doctrines
+
+Learning MUST NEVER:
+
+- Override a law
+- Weaken an invariant
+- Introduce exceptions
+- Redefine system boundaries
+
+If learning conflicts with doctrine,  
+the learning MUST be **REJECTED**.
+
+---
+
+## 3. Learning Trigger Law
+
+Learning is triggered **ONLY** when at least one of the following occurs:
+
+- A previous agent decision is explicitly corrected
+- A demonstrably superior approach is provided
+- Architectural or systemic reasoning is overridden by the user
+
+Providing code alone  
+does **NOT** trigger learning.
+
+---
+
+## 4. Learning Boundary Law (HARD LIMITS)
+
+The system MUST NEVER learn or internalize:
+
+- Code style or formatting preferences
+- Naming conventions
+- Temporary workarounds
+- Project-specific hacks
+- One-off optimizations
+- UI or aesthetic preferences
+
+Learning MUST target **generalizable reasoning**,  
+never local fixes.
+
+---
+
+## 5. Learning Extraction Protocol
+
+When learning is triggered, the system MUST:
+
+1. Identify the **incorrect assumption**
+2. Identify **why the new reasoning is superior**
+3. Abstract a **technology-agnostic principle**
+4. Validate the principle against all doctrines
+5. Apply learning **only to future reasoning**
+
+If a principle cannot be clearly articulated,  
+learning MUST be **ABORTED**.
+
+---
+
+## 6. Predictability Enforcement Law
+
+Learning MUST increase predictability.
+
+Learning is INVALID if it:
+
+- Surprises an experienced engineer
+- Introduces inconsistent decisions
+- Requires special context to be safe
+- Produces different answers for the same problem
+
+Predictability outranks adaptability.
+
+---
+
+## 7. Learning Rollback Rule
+
+All learning MUST be:
+
+- Explicit
+- Auditable
+- Reversible
+
+If learning degrades system trust or clarity,  
+it MUST be **ROLLED BACK** immediately.
+
+Silent behavioral drift is **FORBIDDEN**.
+
+---
+
+## 8. AI Agent Constraints
+
+AI agents operating under CoinPika:
+
+- Are proposal-only
+- Have zero trust by default
+- Cannot approve or merge changes
+- Must cite applicable doctrines
+- Must explain reasoning transparently
+
+AI assistance MUST NEVER  
+replace human accountability.
+
+---
+
+## 9. Enforcement Rule
+
+Any learning behavior that:
+
+- Weakens doctrine
+- Introduces ambiguity
+- Accumulates exceptions
+- Reduces predictability
+
+**MUST BE DISABLED**.
+
+System safety overrides learning ambition.
+
+---
+
+## Final Authority
+
+This doctrine overrides:
+
+- Adaptive heuristics
+- “Smart” optimizations
+- Self-modifying behavior
+- Unbounded AI learning
+
+CoinPika learns to protect:
+
+**Correctness · Predictability · Trust**
+
+Not novelty.
+
+---
+
+**Status:** LOCKED  
+**Version:** 1.0.0  
+**Parent:** CoinPika Architecture Doctrine  
+**Override Permission:** NONE  

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

@@ -0,0 +1,176 @@
+---
+name: coinpika-performance-doctrine
+version: 1.0.0
+status: LOCKED
+authority: CONSTITUTIONAL
+parent: coinpika-architecture-doctrine
+---
+
+# ⚡ CoinPika Performance Doctrine  
+**(Perceived Speed · Stability · Trust Law)**
+
+This doctrine defines the **non-negotiable performance laws**
+governing how CoinPika loads, renders, updates, and feels to users.
+
+Performance is **NOT a metric**.  
+Performance is **user trust over time**.
+
+A fast but unstable system erodes trust.  
+A slightly stale but stable system preserves trust.
+
+---
+
+## 1. Performance Philosophy
+
+CoinPika prioritizes **perceived performance** over raw technical freshness.
+
+Users judge speed by:
+
+- How fast something appears
+- How stable it feels
+- Whether it surprises them
+
+Not by how fresh the data is at the millisecond level.
+
+---
+
+## 2. Immediate Feedback Law (NON-NEGOTIABLE)
+
+If cached or previously known data exists:
+
+- It MUST be rendered immediately
+- It MUST NOT wait for the network
+- It MUST NOT show loading spinners
+
+Waiting for the network when usable data exists  
+is a **UX FAILURE**.
+
+---
+
+## 3. Background Freshness Law
+
+Data freshness MUST be resolved **asynchronously**.
+
+Rules:
+
+- UI MUST NOT block initial render
+- UI MUST NOT flicker or reflow
+- UI MUST NOT clear existing content
+- UI MUST NOT replace data with spinners
+
+Freshness is corrected quietly in the background.
+
+---
+
+## 4. Stability Over Accuracy Law
+
+A stable UI with slightly stale data is preferable to:
+
+- Loading spinners
+- Flickering content
+- Layout shifts
+- Jarring re-renders
+
+Accuracy matters —  
+but NEVER at the cost of visual stability.
+
+---
+
+## 5. No Synchronous Network Dependency Law
+
+The UI MUST NEVER synchronously depend on
+network responses for initial render.
+
+The ONLY allowed exceptions are:
+
+- Authentication flows
+- Security-critical validation
+
+Everything else MUST degrade gracefully.
+
+---
+
+## 6. Consistency Across States Law
+
+Performance behavior MUST be consistent across:
+
+- Cold load
+- Warm load
+- Page refresh
+- Navigation transitions
+
+If performance differs between these states,  
+the system is **INCONSISTENT**.
+
+Inconsistency erodes trust faster than slowness.
+
+---
+
+## 7. Performance Anti-Patterns (ZERO TOLERANCE)
+
+The following are considered **performance violations**:
+
+- Blocking render on data freshness
+- Replacing cached data with loading states
+- Clearing content during background refresh
+- Triggering full re-renders on incremental updates
+- Using spinners where cached data exists
+- Treating “loading” as a default state
+
+These patterns MUST be **REJECTED**, not optimized.
+
+---
+
+## 8. Decision Priority Order
+
+When performance trade-offs exist,
+decisions MUST be made in this order:
+
+1. User-perceived speed
+2. Visual stability
+3. Predictability
+4. Data freshness
+5. Technical elegance
+
+If a solution violates **#1 or #2**,  
+it is **INVALID** — regardless of benchmarks.
+
+---
+
+## 9. Enforcement Rule
+
+Any change that:
+
+- Makes the UI feel slower
+- Introduces flicker or instability
+- Surprises returning users
+- Improves metrics but degrades experience
+
+**MUST NOT BE MERGED**.
+
+Missed performance metrics are recoverable.  
+Lost user trust is not.
+
+---
+
+## Final Authority
+
+This doctrine overrides:
+
+- Framework defaults
+- Micro-optimizations
+- Blog-driven “best practices”
+- Benchmark obsession
+
+CoinPika performance exists to protect:
+
+**Speed Perception · Stability · User Trust**
+
+Not numbers on a dashboard.
+
+---
+
+**Status:** LOCKED  
+**Version:** 1.0.0  
+**Parent:** CoinPika Architecture Doctrine  
+**Override Permission:** NONE  

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

@@ -0,0 +1,170 @@
+---
+name: coinpika-code-review-doctrine
+version: 1.0.0
+status: LOCKED
+authority: CONSTITUTIONAL
+parent: coinpika-architecture-doctrine
+---
+
+# 🛡️ CoinPika Code Review Doctrine  
+**(Engineering Review · Enforcement · System Integrity Law)**
+
+This doctrine defines the **non-negotiable laws** governing how code is reviewed,
+approved, or rejected in CoinPika.
+
+Code review exists to:
+- Protect system correctness
+- Prevent architectural erosion
+- Preserve long-term maintainability
+- Enforce constitutional law
+
+Approval is an act of **responsibility**,  
+not politeness.
+
+---
+
+## 1. Reviewer Role & Authority
+
+A reviewer is the **guardian of the system**,
+not a collaborator seeking compromise.
+
+If a proposed change threatens:
+
+- Data integrity
+- Architectural boundaries
+- System invariants
+- User trust
+- Commercial safety
+
+The reviewer **MUST BLOCK** it,  
+regardless of effort, intent, or sunk cost.
+
+---
+
+## 2. Review Priority Order (NON-NEGOTIABLE)
+
+All code MUST be evaluated in the following order:
+
+1. CoinPika Master Constitution
+2. Architecture & System Doctrines
+3. Commercial Guardrails
+4. Performance Doctrine
+5. Functional correctness
+6. Long-term maintainability
+7. Style & readability
+
+If a change fails at a higher level,  
+lower-level qualities are **IRRELEVANT**.
+
+---
+
+## 3. Mandatory Blocking Conditions
+
+A change **MUST BE REJECTED** if it:
+
+- Violates any doctrine or system law
+- Introduces ambiguity in data ownership
+- Creates page-specific or feature-specific behavior
+- Adds hidden coupling or implicit dependencies
+- Fixes symptoms instead of root causes
+- Introduces “temporary” violations
+
+“Works as intended”  
+is **NOT** sufficient justification.
+
+---
+
+## 4. Local vs System Correctness Law
+
+Local correctness does **NOT** imply system correctness.
+
+If a locally correct change:
+
+- Breaks global invariants
+- Adds special cases or exceptions
+- Requires future engineers to “remember rules”
+
+Then it **MUST BE REJECTED**.
+
+Systems must be safe by design,  
+not safe by memory.
+
+---
+
+## 5. Reviewer Obligations
+
+When blocking a change, the reviewer MUST:
+
+- Cite the violated doctrine or law explicitly
+- Explain the **systemic risk**, not just the bug
+- Suggest a compliant direction (not implementation)
+
+Review feedback must improve
+**system understanding**, not just code quality.
+
+---
+
+## 6. Review Anti-Patterns (ZERO TOLERANCE)
+
+The following behaviors are **STRICTLY FORBIDDEN**:
+
+- Approving code “to unblock progress”
+- Deferring architectural fixes
+- Accepting “temporary” violations
+- Allowing undocumented exceptions
+- Prioritizing speed over correctness
+
+These behaviors accumulate
+**technical debt and organizational debt**.
+
+---
+
+## 7. Escalation & Disagreement Rule
+
+If disagreement arises:
+
+- Escalate to higher authority doctrine
+- Defer to constitutional precedence
+- Do NOT compromise system safety
+
+Consensus is secondary to correctness.
+
+---
+
+## 8. Enforcement Rule
+
+Any change that:
+
+- Compromises long-term integrity
+- Weakens architectural law
+- Increases cognitive load for future engineers
+- Surprises an experienced reviewer
+
+**MUST NOT BE MERGED**.
+
+Missed deadlines are recoverable.  
+System erosion is not.
+
+---
+
+## Final Authority
+
+This doctrine overrides:
+
+- Personal relationships
+- Reviewer fatigue
+- Delivery pressure
+- “It works” arguments
+
+CoinPika code review exists to protect:
+
+**Correctness · Architecture · Trust**
+
+Not velocity.
+
+---
+
+**Status:** LOCKED  
+**Version:** 1.0.0  
+**Parent:** CoinPika Architecture Doctrine  
+**Override Permission:** NONE