@polymorphism-tech/morph-spec 4.22.0 → 5.0.1

package/framework/skills/level-0-meta/morph-brainstorming/SKILL.md

@@ -1,174 +0,0 @@
----
-name: morph-brainstorming
-description: Morph-spec-aware brainstorming that loads project context, explores multiple design approaches, asks clarifying questions, and produces proposal.md or decisions.md. Use before designing a feature, when facing architectural decisions with multiple valid approaches, or when a feature needs requirements exploration before committing to a direction.
-user-invocable: true
-argument-hint: "[feature-name or topic]"
-allowed-tools: Read, Bash, Glob, Grep, AskUserQuestion
----
-
-# Brainstorming — MORPH-SPEC Integrated
-
-> Explore context, ask questions, generate multiple approaches, and produce a design document before committing to implementation.
->
-> **Example:** `references/proposal-example.md` — filled-in proposal.md showing expected quality.
-
-## When to Use
-
-- **Phase 0 (Proposal):** Explore the feature request before writing `proposal.md`
-- **Phase 2 (Design):** Explore architectural alternatives before writing `spec.md`
-- **Any phase:** When facing a decision with multiple valid approaches
-
-## Recommended Tools
-
-| Action | Tool | Alternative |
-|--------|------|-------------|
-| Load feature state | **Bash** `morph-spec state get $ARGUMENTS` | — |
-| Read project config | **Read** `.morph/config/config.json` | — |
-| Scan existing code | **Glob** / **Grep** | — |
-| Research libraries | **Context7 MCP** `query_docs()` | **WebSearch** |
-| Ask clarifying questions | **AskUserQuestion** (never plain text) | — |
-| Render proposal template | **Bash** `morph-spec template render docs/proposal ...` | — |
-
----
-
-## Workflow
-
-## MANDATORY: Session Tasks
-
-> **BEFORE starting any brainstorming work**, analyze what you need to do and create session tasks.
->
-> **Rules:** Minimum 2 tasks, typically 3-5. Mark `in_progress` before starting, `completed` after.
->
-> **Typical tasks:** context exploration, clarifying questions, approach analysis, recommendation, documentation
-
-### Step 1: Explore Context
-
-Gather information before generating ideas. This step is what makes morph-aware brainstorming different from generic brainstorming — it grounds your thinking in the actual project state and constraints.
-
-1. **Read state** — `morph-spec state get $ARGUMENTS` → current phase, active agents, existing outputs, task history
-2. **Read config** — `.morph/config/config.json` → stack, architecture style (VSA vs standard), project name, integrations
-3. **Check architecture** — `cat .morph/config/config.json | grep -A3 architecture` → determines which agents and patterns apply
-4. **Read existing outputs** — proposal.md, spec.md, decisions.md (if they exist from prior work)
-5. **Check active agents** — `morph-spec dispatch-agents $ARGUMENTS design --table` → which specialists are available
-6. **Scan codebase** — use Glob/Grep to understand existing patterns, domain models, and service boundaries relevant to the feature
-7. **Check MCP tools** — if Context7, GitHub, or other MCPs are available, use them for research
-
-### Step 1.5: Assess Complexity & Recommend Workflow
-
-Based on the context gathered in Step 1, evaluate the feature's complexity to select the appropriate workflow tier. Use this decision table:
-
-| Indicator | Fast-Track | Standard | Full |
-|-----------|-----------|----------|------|
-| Files affected | 1-3 | 3-10 | 10+ |
-| Entities/domains | 1 | 1-2 | 3+ |
-| External integrations | None | None | 1+ |
-| Infrastructure changes | No | No | Yes |
-| UI design needed | No | Optional | Yes |
-| Examples | CRUD field, rename, toggle, fix | Pagination, filter, export, refactor | Auth system, migration, platform redesign |
-
-**Actions:**
-1. Count entities, domains, integrations, and UI requirements from the feature request
-2. Match against the table above to determine the tier
-3. Set the workflow in state:
-   ```bash
-   morph-spec state set $ARGUMENTS workflow fast-track   # or standard / full
-   ```
-4. Inform the user of the recommendation via `AskUserQuestion` with options to confirm or override:
-   - Header: `Workflow`
-   - Question: "Based on complexity analysis, I recommend **{tier}** workflow ({N} phases). Override?"
-   - Options: `Confirm {tier}` / `Switch to standard` / `Switch to full` / `Switch to fast-track`
-
-> **Note:** The user can always override later with `morph-spec state set <feature> workflow <tier>`.
-
-### Step 2: Ask Clarifying Questions
-
-Use `AskUserQuestion` to collect responses — **NEVER list questions as plain text**.
-
-- Maximum 4 questions per call. If you need 5+, make sequential calls (Q1-Q4, then Q5).
-- Each question needs 2-4 representative options (the user can type a free response via "Other").
-- **Wait for the tool response before proceeding to Step 3.**
-
-Starter questions to adapt to the feature context:
-
-| Header (<=12 chars) | Question | Suggested Options |
-|--------------------|----------|------------------|
-| `Scope` | What's the minimum viable version of this feature? | Basic MVP / Full version / Open-ended |
-| `Constraints` | Any performance, budget, or timeline constraints? | No constraints / Performance-critical / Budget-limited |
-| `Integration` | Does this need to integrate with existing features/systems? | Yes, integrates with X / Isolated feature / TBD |
-| `Users` | Who are the primary users? | End-users / Admins / Internal system |
-| `Success` | How will we know this feature works correctly? | Defined metrics / Acceptance tests / User feedback |
-
-> Adapt the options to the actual feature context — these are starting points, not a fixed template.
-
-### Step 3: Generate 2-3 Approaches
-
-For each approach, document:
-
-```markdown
-## Approach A: {Name}
-
-**Description:** {1-2 sentences}
-
-**Pros:**
-- Pro 1
-- Pro 2
-
-**Cons:**
-- Con 1
-- Con 2
-
-**Complexity:** Low / Medium / High
-**Estimated Tasks:** ~N
-**Key Dependencies:** {list}
-```
-
-### Step 4: Recommend and Document
-
-1. **Recommend** the best approach with clear reasoning
-2. **Write output** to the appropriate location based on the current phase:
-
-   **Phase 0 (Proposal):**
-   ```bash
-   morph-spec template render docs/proposal ".morph/features/$ARGUMENTS/0-proposal/proposal.md" '{"FEATURE_NAME":"...", "DATE":"..."}'
-   ```
-   Then edit the rendered file to add the brainstorming results.
-
-   **Phase 2 (Design):**
-   Write the decision as an ADR (Architecture Decision Record) in `.morph/features/$ARGUMENTS/2-design/decisions.md`.
-
-3. **Update state** (mandatory — do not skip):
-   ```bash
-   morph-spec state mark-output $ARGUMENTS proposal    # Phase 0
-   morph-spec state mark-output $ARGUMENTS decisions    # Phase 2
-   ```
-   Then verify the output was recorded:
-   ```bash
-   morph-spec state get $ARGUMENTS
-   ```
-
----
-
-## Integration with Superpowers
-
-> Available when the `superpowers` plugin is installed.
-
-This skill replaces `superpowers:brainstorming` within morph-spec workflows. It adds:
-- Automatic context loading from `.morph/` state and config
-- Template rendering for outputs (proposal.md, decisions.md)
-- State tracking via `morph-spec state mark-output`
-- MCP integration for research (Context7, GitHub)
-
-For brainstorming **outside** morph-spec workflows, the original `superpowers:brainstorming` skill remains available.
-
----
-
-## Anti-patterns
-
-- Skipping brainstorming for features with multiple valid approaches — exploring alternatives prevents tunnel vision
-- Committing to an approach without documenting alternatives — future decisions need context on what was considered
-- Brainstorming without loading project context first — leads to approaches that don't fit the existing architecture
-- Writing code before completing the brainstorming output — premature implementation before agreement
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-0-meta/morph-brainstorming/references/proposal-example.md

@@ -1,138 +0,0 @@
-# Feature Proposal: Photo Processing Pipeline
-
-> Example of a well-structured proposal.md. This is a filled-in reference — not a template.
-
-## Metadata
-
-| Field | Value |
-|-------|-------|
-| **Proposed** | 2025-01-15 |
-| **Author** | Product Team |
-| **Status** | Approved |
-| **Priority** | High |
-| **Stack** | blazor-azure |
-
----
-
-## Overview
-
-Users currently cannot upload photos for AI-based transformations because no upload infrastructure exists. This feature adds an end-to-end photo upload, processing, and delivery pipeline using Azure Blob Storage and Hangfire background jobs.
-
----
-
-## Problem Statement
-
-### What is the problem?
-
-Users cannot submit photos for AI transformation, blocking the core product value proposition. The system has no file upload capability, no background processing queue, and no way to notify users when processing completes.
-
-### Who is affected?
-
-All end users who want to use the photo transformation feature — the primary user journey is completely unavailable.
-
-### What is the impact?
-
-- User productivity loss: 100% of core use case unavailable
-- Revenue impact: Feature is the primary paid tier differentiator
-- User satisfaction: Can't demo product to prospects
-
----
-
-## Proposed Solution
-
-### Overview
-
-A multi-step pipeline: user uploads a photo via a Blazor form → the file is stored in Azure Blob Storage → a Hangfire background job is queued for AI processing → the user polls for completion → the processed photo is returned via a download link.
-
-### Key Features
-
-1. **Upload endpoint** — Validates file type/size, stores in Azure Blob
-2. **Background processing** — Hangfire job calls AI API, stores result in Blob
-3. **Status polling** — User sees real-time progress (Pending → Processing → Completed)
-
-### User Journey
-
-```
-1. User selects a photo file on the upload page
-2. System validates (max 10MB, .jpg/.png only) and shows preview
-3. User clicks "Upload" → system enqueues job, redirects to /processing/{jobId}
-4. User sees progress bar polling every 5 seconds
-5. On completion: "Download" button appears, user gets processed photo
-```
-
----
-
-## Success Metrics
-
-| Metric | Current | Target |
-|--------|---------|--------|
-| Upload success rate | N/A | >99% |
-| Processing time (p95) | N/A | <120s |
-| Error recovery rate | N/A | >95% (auto-retry) |
-
----
-
-## Scope
-
-### In Scope
-
-- Photo upload (Blazor form, Azure Blob Storage)
-- Background processing via Hangfire
-- Status polling page with progress indicator
-- Download link for processed photo
-- Basic error handling and retry logic
-
-### Out of Scope
-
-- Batch uploads (multiple photos at once)
-- Email notifications when processing completes
-- Photo editing before upload (crop, resize)
-
-### Future Considerations
-
-- Webhooks for external integrations
-- Processing history and gallery view
-
----
-
-## Risks & Concerns
-
-| Risk | Likelihood | Impact | Mitigation |
-|------|------------|--------|------------|
-| AI API unavailable | Medium | High | Retry with exponential backoff, fallback error state |
-| Large file upload timeout | Low | Medium | Chunked upload or presigned URL direct to Blob |
-| Blob storage costs unexpectedly high | Low | Low | Set blob lifecycle policy (auto-delete after 30 days) |
-
----
-
-## Estimated Effort
-
-| Phase | Estimate |
-|-------|----------|
-| Design & Spec | 2h |
-| Implementation | 6h |
-| Testing | 2h |
-| **Total** | **10h** |
-
----
-
-## Questions & Clarifications
-
-1. Maximum file size: 10MB or higher for pro users?
-2. Should processed photos be kept indefinitely or expire after 30 days?
-3. Does the AI API support async webhooks or only polling?
-
----
-
-## Next Steps
-
-Once approved:
-1. Create detailed `spec.md` with technical design
-2. Define contracts in `contracts.cs`
-3. Record decisions in `decisions.md`
-4. Break down into `tasks.md`
-5. Begin implementation
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-0-meta/morph-checklist/SKILL.md

@@ -1,145 +0,0 @@
----
-name: morph-checklist
-description: Pre-deploy, security, SEO, performance, accessibility, and LGPD compliance checklists for MORPH-SPEC projects. Use before deploying to production, during security audits, when optimizing for SEO or performance, or when validating Brazilian LGPD data protection compliance.
-user-invocable: true
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
----
-
-# MORPH Checklists
-
-Types: `deploy`, `security`, `seo`, `performance`, `accessibility`, `legal-brazil`, `simulation` (see skill: `morph-simulation-checklist`)
-
----
-
-## Deploy
-
-### MORPH-SPEC Validation (run first)
-- [ ] `morph-spec validate-feature {feature}` — passes with 100% pass rate
-- [ ] `morph-spec approval-status {feature}` — all gates approved (design, plan, tasks)
-- [ ] `morph-spec state get {feature}` — phase is `implement`, all tasks `done`
-- [ ] Recap generated: `.morph/features/{feature}/5-implement/recap.md` exists
-
-### Pre-Deploy
-- [ ] `dotnet build --configuration Release` passes
-- [ ] `dotnet test` passes (100% pass rate required — zero tolerance)
-- [ ] Migrations applied (`dotnet ef database update`)
-- [ ] Env vars configured (connection strings, API keys, feature flags)
-
-### Infrastructure
-- [ ] Bicep/IaC updated (`az deployment group what-if`)
-- [ ] SSL/HTTPS configured
-- [ ] DNS pointing correctly
-- [ ] Health checks configured
-
-### Security & Monitoring
-- [ ] Secrets in Key Vault (not in code)
-- [ ] Managed Identity configured
-- [ ] CORS configured
-- [ ] Rate limiting enabled
-- [ ] Application Insights + alerts configured
-
-### Post-Deploy
-- [ ] Smoke tests executed
-- [ ] Rollback plan documented
-
----
-
-## Security
-
-### Auth & Authorization
-- [ ] Passwords hashed (bcrypt/Argon2), MFA available
-- [ ] JWT with short expiration + refresh tokens
-- [ ] RBAC + resource-based authorization
-- [ ] Ownership verification (user sees only their data)
-
-### Input & Headers
-- [ ] Server-side validation (never trust client)
-- [ ] HTML sanitized (XSS), parametrized queries (SQLi)
-- [ ] File upload validation (type, size, content)
-- [ ] Security headers: `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `CSP: default-src 'self'`
-
-### Data
-- [ ] PII encrypted at rest, masked in logs
-- [ ] Card data never stored (use tokenization)
-- [ ] `dotnet list package --vulnerable` clean
-
----
-
-## SEO
-
-- [ ] `<title>` + `<meta description>` (150-160 chars)
-- [ ] `<link rel="canonical">` + `robots.txt` + `sitemap.xml`
-- [ ] Open Graph tags (og:title, og:description, og:image)
-- [ ] URLs friendly, heading hierarchy (H1>H2>H3)
-- [ ] Images optimized (WebP, lazy loading, alt text)
-- [ ] Core Web Vitals: LCP < 2.5s, FID < 100ms, CLS < 0.1
-
----
-
-## Performance
-
-### Backend
-- [ ] `.AsNoTracking()` for reads, no N+1, projections (`.Select()`)
-- [ ] Indexes on search columns
-- [ ] Response/distributed caching with invalidation
-- [ ] All I/O operations are async (no `.Result` / `.Wait()`)
-
-### Frontend
-- [ ] Lazy loading, virtualization for large lists
-- [ ] Debounce search inputs
-- [ ] Memoization for expensive renders
-
-### Infrastructure
-- [ ] CDN for static assets, gzip/brotli compression
-- [ ] Connection pooling, scale-to-zero
-
----
-
-## Accessibility (WCAG 2.1)
-
-- [ ] Alt text on images, captions on videos
-- [ ] Contrast >= 4.5:1 (AA), color not sole indicator
-- [ ] Keyboard navigation works, focus visible
-- [ ] Skip links, `<html lang="...">` with correct locale
-- [ ] Labels on all inputs, clear error messages
-- [ ] Valid HTML, ARIA used correctly
-
----
-
-## Legal Brazil (LGPD — Lei 13.709/2018)
-
-The Brazilian General Data Protection Law (LGPD) applies to any application that processes personal data of individuals in Brazil. Non-compliance can result in fines up to 2% of revenue (capped at R$50M per violation) from ANPD (Autoridade Nacional de Protecao de Dados).
-
-### Documentation (Art. 9, 23, 41)
-- [ ] Privacy policy published and accessible from every page — must include: categories of data collected, legal basis per category (Art. 7), processing purpose, retention period, DPO (Encarregado) contact name and email
-- [ ] Terms of use covering: service description, user responsibilities, governing forum (Brazilian jurisdiction required)
-- [ ] ROPA (Record of Processing Activities) — internal document mapping data flows per Art. 37
-
-### Consent & Data Subject Rights (Art. 7-9, 15-18)
-- [ ] Cookie consent banner with **granular opt-in** (not just "accept all") — separate toggles for analytics, marketing, essential
-- [ ] Explicit consent for marketing communications — checkbox unchecked by default, revocable at any time
-- [ ] Data subject rights page implementing all Art. 18 rights:
-  - [ ] Access: user can view all personal data held
-  - [ ] Correction: user can update inaccurate data
-  - [ ] Deletion: user can request full account/data deletion (Art. 18, IX)
-  - [ ] Portability: user can export data in machine-readable format (JSON/CSV)
-  - [ ] Opposition: user can object to specific processing
-- [ ] Rights requests processed within 15 days (Art. 19)
-
-### Technical Controls (Art. 46-49)
-- [ ] PII encrypted at rest (AES-256) and in transit (TLS 1.2+)
-- [ ] Data minimization: only collect what the legal basis justifies
-- [ ] Defined retention periods per data category — automatic purge after expiry
-- [ ] Anonymization/pseudonymization for analytics and logs
-- [ ] Access logs for all personal data operations (who accessed what, when)
-- [ ] Incident response plan: ANPD notification within **72 hours** of breach (Art. 48), user notification "within reasonable time"
-- [ ] Data Protection Impact Assessment (DPIA/RIPD) for high-risk processing (Art. 5, XVII)
-
-### DPO (Encarregado — Art. 41)
-- [ ] DPO designated and publicly identified (name + contact on privacy policy)
-- [ ] DPO contact channel operational (email or form)
-- [ ] DPO handles ANPD communications and data subject requests
-
----
-
-*MORPH-SPEC Checklist Skill*