@polymorphism-tech/morph-spec 4.10.9 → 4.10.10

package/framework/templates/examples/spec-examples.md

@@ -1,90 +1,90 @@
-# Spec Template Reference
-
-> **Layer:** 3 | **Load:** on-demand | **Keywords:** spec, specification, template
-
-**Use the stack's `.morph/framework/templates/spec.md` as the canonical template.**
-
-This file contains extended examples for each spec section.
-
----
-
-## Example: Entity (Pseudo-code)
-
-```csharp
-class ProcessingJob {
-  Guid Id
-  string OriginalPhotoUrl     // Azure Blob URL, max 500 chars
-  string? ProcessedPhotoUrl   // Nullable, populated after processing
-  ProcessingStatus Status     // Enum: Pending, Processing, Completed, Failed
-  DateTime CreatedAt
-  ICollection<ExecutionLog> Logs  // 1:N relationship
-}
-
-enum ProcessingStatus {
-  Pending = 0, Processing = 1, Completed = 2,  // Normal flow
-  Failed = 100                                   // Error states (high values)
-}
-```
-
-## Example: Command (Pseudo-code)
-
-```csharp
-UploadPhotoCommand {
-  Input: IFormFile photo, string? email
-  Output: Guid jobId
-
-  Handler:
-    1. Validate file (size <= 10MB, type in [.jpg, .png])
-    2. Upload to Azure Blob Storage
-    3. Create ProcessingJob entity (status = Pending)
-    4. Enqueue Hangfire background job
-    5. Return jobId
-}
-```
-
-## Example: API Endpoints
-
-```csharp
-PhotoProcessingController {
-  POST /api/upload        → multipart/form-data → { jobId: Guid }
-  GET  /api/status/{id}   → jobId → { status, progress, createdAt }
-  GET  /api/download/{id} → jobId → Redirect to Blob URL or 404
-}
-```
-
-## Example: Flow
-
-```
-Upload Flow (Actor: User)
-1. User selects photo → System validates (size, type) → If invalid: show error
-2. User sees preview → clicks "Upload"
-3. System creates ProcessingJob → uploads to Blob → enqueues Hangfire job → returns jobId
-4. System navigates to /processing/{jobId} → polls every 5s
-End State: User on progress page, job processing in background
-```
-
-## Example: ADR
-
-### ADR-001: Use Hangfire for Background Jobs
-**Status:** Accepted
-**Context:** Need background processing for AI photo transformation (30-120s).
-**Decision:** Hangfire (self-hosted).
-**Alternatives:**
-1. Azure Functions — serverless, auto-scaling, but cold start + $10/mo for 50k jobs
-2. Hangfire — zero cost, simpler, but scales with app
-3. Quartz.NET — more features, but steeper learning curve
-**Trade-offs:** Simplicity vs Features (Hangfire sufficient for MVP)
-
-## Example: Cost Estimate
-
-| Resource | SKU | Monthly | Justification |
-|----------|-----|---------|---------------|
-| Blob Storage | LRS | $0.02 | Store photos, low redundancy OK |
-| Azure SQL | Basic | $4.99 | < 100k jobs/month |
-| Container App | Consumption | $0.49 | Scale to zero |
-| Hangfire | Self-hosted | $0.00 | In-process |
-| **Total** | | **~$5.50** | |
-
----
-
-*MORPH-SPEC by Polymorphism Tech*
+# Spec Template Reference
+
+> **Layer:** 3 | **Load:** on-demand | **Keywords:** spec, specification, template
+
+**Use the stack's `.morph/framework/templates/spec.md` as the canonical template.**
+
+This file contains extended examples for each spec section.
+
+---
+
+## Example: Entity (Pseudo-code)
+
+```csharp
+class ProcessingJob {
+  Guid Id
+  string OriginalPhotoUrl     // Azure Blob URL, max 500 chars
+  string? ProcessedPhotoUrl   // Nullable, populated after processing
+  ProcessingStatus Status     // Enum: Pending, Processing, Completed, Failed
+  DateTime CreatedAt
+  ICollection<ExecutionLog> Logs  // 1:N relationship
+}
+
+enum ProcessingStatus {
+  Pending = 0, Processing = 1, Completed = 2,  // Normal flow
+  Failed = 100                                   // Error states (high values)
+}
+```
+
+## Example: Command (Pseudo-code)
+
+```csharp
+UploadPhotoCommand {
+  Input: IFormFile photo, string? email
+  Output: Guid jobId
+
+  Handler:
+    1. Validate file (size <= 10MB, type in [.jpg, .png])
+    2. Upload to Azure Blob Storage
+    3. Create ProcessingJob entity (status = Pending)
+    4. Enqueue Hangfire background job
+    5. Return jobId
+}
+```
+
+## Example: API Endpoints
+
+```csharp
+PhotoProcessingController {
+  POST /api/upload        → multipart/form-data → { jobId: Guid }
+  GET  /api/status/{id}   → jobId → { status, progress, createdAt }
+  GET  /api/download/{id} → jobId → Redirect to Blob URL or 404
+}
+```
+
+## Example: Flow
+
+```
+Upload Flow (Actor: User)
+1. User selects photo → System validates (size, type) → If invalid: show error
+2. User sees preview → clicks "Upload"
+3. System creates ProcessingJob → uploads to Blob → enqueues Hangfire job → returns jobId
+4. System navigates to /processing/{jobId} → polls every 5s
+End State: User on progress page, job processing in background
+```
+
+## Example: ADR
+
+### ADR-001: Use Hangfire for Background Jobs
+**Status:** Accepted
+**Context:** Need background processing for AI photo transformation (30-120s).
+**Decision:** Hangfire (self-hosted).
+**Alternatives:**
+1. Azure Functions — serverless, auto-scaling, but cold start + $10/mo for 50k jobs
+2. Hangfire — zero cost, simpler, but scales with app
+3. Quartz.NET — more features, but steeper learning curve
+**Trade-offs:** Simplicity vs Features (Hangfire sufficient for MVP)
+
+## Example: Cost Estimate
+
+| Resource | SKU | Monthly | Justification |
+|----------|-----|---------|---------------|
+| Blob Storage | LRS | $0.02 | Store photos, low redundancy OK |
+| Azure SQL | Basic | $4.99 | < 100k jobs/month |
+| Container App | Consumption | $0.49 | Scale to zero |
+| Hangfire | Self-hosted | $0.00 | In-process |
+| **Total** | | **~$5.50** | |
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*

package/framework/templates/feature/decisions.md

@@ -1,187 +1,187 @@
-# Architecture Decision Records - {{titleCase FEATURE_NAME}}
-
-## ADR-001: {Decision Title}
-
-**Date:** {{DATE}}
-**Status:** Proposed | Accepted | Deprecated | Superseded
-**Deciders:** MORPH Agents, Developer
-
-### Context
-
-{Describe the context and problem that led to this decision}
-
-### Decision
-
-{Describe the decision made}
-
-### Consequences
-
-**Pros:**
-- {Positive consequence 1}
-- {Positive consequence 2}
-
-**Cons:**
-- {Negative consequence 1}
-
-**Risks:**
-- {Identified risk}
-
-### Alternatives Considered
-
-#### Option A: {Name}
-- Pros: {advantages}
-- Cons: {disadvantages}
-- **Rejected because:** {reason}
-
-#### Option B: {Name}
-- Pros: {advantages}
-- Cons: {disadvantages}
-- **Rejected because:** {reason}
-
-{{#if (eq STACK "blazor-azure")}}
-### Affected Flows
-- **Main flow:** {ex: Upload -> Payment -> Generation -> Email}
-- **Alternative flow:** {ex: Upload -> Generation -> Payment -> Email}
-- **Free flow:** {ex: Upload -> Generation -> Download}
-
-### Impacted State Validations
-
-> **Reference:** `framework/standards/status-validation.md`
-
-| Service | Method | Accepted States |
-|---------|--------|-----------------|
-| {ServiceName} | {MethodName} | {ex: PendingPayment, Completed} |
-
-### UI Components with Special Behavior
-- {ex: FluentDialog requires initial Hidden="true"}
-- {ex: Modal needs @ref for programmatic control}
-{{/if}}
-
----
-
-{{#if (eq STACK "blazor-azure")}}
-## ADR-002: Database Model
-
-**Date:** {{DATE}}
-**Status:** Accepted
-
-### Context
-
-Need to define how {Feature} data will be stored.
-
-### Decision
-
-Use Azure SQL with the following model:
-- {Entity} table with {columns}
-- JSON columns for {flexible data}
-
-### Consequences
-
-**Pros:**
-- Fits within free tier (32GB)
-- Good query performance
-
----
-
-## ADR-003: AI Integration
-
-**Date:** {{DATE}}
-**Status:** Accepted
-
-### Context
-
-Feature requires AI capabilities for {purpose}.
-
-### Decision
-
-Use MS Agent Framework with gpt-4o-mini model.
-
-### Consequences
-
-**Pros:**
-- Cost effective (~$0.15/1M input tokens)
-- Good enough quality for this use case
-
-**Cons:**
-- Slightly less capable than gpt-4o
-{{/if}}
-
-{{#if (eq STACK "nextjs-supabase")}}
-## ADR-002: Database Access Strategy
-
-**Date:** {{DATE}}
-**Status:** Accepted
-
-### Context
-
-Need to decide how the .NET API accesses Supabase PostgreSQL.
-
-### Decision
-
-Use Dapper with Npgsql for direct SQL queries. No EF Core.
-
-### Consequences
-
-**Pros:**
-- Full control over SQL queries
-- Better performance (no ORM overhead)
-- Direct access to PostgreSQL features (jsonb, pgvector, functions)
-- RLS policies apply naturally through connection
-
-**Cons:**
-- No automatic migrations (use Supabase CLI instead)
-- Manual SQL query writing
-- No change tracking
-
----
-
-## ADR-003: Auth Strategy
-
-**Date:** {{DATE}}
-**Status:** Accepted
-
-### Context
-
-Need authentication for both Next.js frontend and .NET API.
-
-### Decision
-
-Use Supabase Auth with @supabase/ssr on frontend. Validate JWT tokens in .NET API middleware.
-
-### Consequences
-
-**Pros:**
-- Single auth provider for both layers
-- RLS policies work automatically with auth.uid()
-- Built-in social login, magic links, email/password
-- No separate auth service to maintain
-
-**Cons:**
-- Coupled to Supabase ecosystem
-- JWT secret must be shared with .NET API
-{{/if}}
-
----
-
-## Template for New ADRs
-
-```markdown
-## ADR-XXX: {Title}
-
-**Date:**
-**Status:** Proposed | Accepted | Deprecated | Superseded
-
-### Context
-{Why is this decision needed?}
-
-### Decision
-{What was decided?}
-
-### Consequences
-**Pros:** {list}
-**Cons:** {list}
-```
-
----
-
-*Generated by MORPH Framework*
+# Architecture Decision Records - {{titleCase FEATURE_NAME}}
+
+## ADR-001: {Decision Title}
+
+**Date:** {{DATE}}
+**Status:** Proposed | Accepted | Deprecated | Superseded
+**Deciders:** MORPH Agents, Developer
+
+### Context
+
+{Describe the context and problem that led to this decision}
+
+### Decision
+
+{Describe the decision made}
+
+### Consequences
+
+**Pros:**
+- {Positive consequence 1}
+- {Positive consequence 2}
+
+**Cons:**
+- {Negative consequence 1}
+
+**Risks:**
+- {Identified risk}
+
+### Alternatives Considered
+
+#### Option A: {Name}
+- Pros: {advantages}
+- Cons: {disadvantages}
+- **Rejected because:** {reason}
+
+#### Option B: {Name}
+- Pros: {advantages}
+- Cons: {disadvantages}
+- **Rejected because:** {reason}
+
+{{#if (eq STACK "blazor-azure")}}
+### Affected Flows
+- **Main flow:** {ex: Upload -> Payment -> Generation -> Email}
+- **Alternative flow:** {ex: Upload -> Generation -> Payment -> Email}
+- **Free flow:** {ex: Upload -> Generation -> Download}
+
+### Impacted State Validations
+
+> **Reference:** `framework/standards/status-validation.md`
+
+| Service | Method | Accepted States |
+|---------|--------|-----------------|
+| {ServiceName} | {MethodName} | {ex: PendingPayment, Completed} |
+
+### UI Components with Special Behavior
+- {ex: FluentDialog requires initial Hidden="true"}
+- {ex: Modal needs @ref for programmatic control}
+{{/if}}
+
+---
+
+{{#if (eq STACK "blazor-azure")}}
+## ADR-002: Database Model
+
+**Date:** {{DATE}}
+**Status:** Accepted
+
+### Context
+
+Need to define how {Feature} data will be stored.
+
+### Decision
+
+Use Azure SQL with the following model:
+- {Entity} table with {columns}
+- JSON columns for {flexible data}
+
+### Consequences
+
+**Pros:**
+- Fits within free tier (32GB)
+- Good query performance
+
+---
+
+## ADR-003: AI Integration
+
+**Date:** {{DATE}}
+**Status:** Accepted
+
+### Context
+
+Feature requires AI capabilities for {purpose}.
+
+### Decision
+
+Use MS Agent Framework with gpt-4o-mini model.
+
+### Consequences
+
+**Pros:**
+- Cost effective (~$0.15/1M input tokens)
+- Good enough quality for this use case
+
+**Cons:**
+- Slightly less capable than gpt-4o
+{{/if}}
+
+{{#if (eq STACK "nextjs-supabase")}}
+## ADR-002: Database Access Strategy
+
+**Date:** {{DATE}}
+**Status:** Accepted
+
+### Context
+
+Need to decide how the .NET API accesses Supabase PostgreSQL.
+
+### Decision
+
+Use Dapper with Npgsql for direct SQL queries. No EF Core.
+
+### Consequences
+
+**Pros:**
+- Full control over SQL queries
+- Better performance (no ORM overhead)
+- Direct access to PostgreSQL features (jsonb, pgvector, functions)
+- RLS policies apply naturally through connection
+
+**Cons:**
+- No automatic migrations (use Supabase CLI instead)
+- Manual SQL query writing
+- No change tracking
+
+---
+
+## ADR-003: Auth Strategy
+
+**Date:** {{DATE}}
+**Status:** Accepted
+
+### Context
+
+Need authentication for both Next.js frontend and .NET API.
+
+### Decision
+
+Use Supabase Auth with @supabase/ssr on frontend. Validate JWT tokens in .NET API middleware.
+
+### Consequences
+
+**Pros:**
+- Single auth provider for both layers
+- RLS policies work automatically with auth.uid()
+- Built-in social login, magic links, email/password
+- No separate auth service to maintain
+
+**Cons:**
+- Coupled to Supabase ecosystem
+- JWT secret must be shared with .NET API
+{{/if}}
+
+---
+
+## Template for New ADRs
+
+```markdown
+## ADR-XXX: {Title}
+
+**Date:**
+**Status:** Proposed | Accepted | Deprecated | Superseded
+
+### Context
+{Why is this decision needed?}
+
+### Decision
+{What was decided?}
+
+### Consequences
+**Pros:** {list}
+**Cons:** {list}
+```
+
+---
+
+*Generated by MORPH Framework*