forgecraft-mcp 1.2.0 → 1.3.2

package/templates/soc2/instructions.yaml

@@ -1,41 +1,41 @@
-tag: SOC2
-section: instructions
-blocks:
-  - id: access-control-validation
-    tier: recommended
-    title: "Access Control Validation"
-    content: |
-      ## Access Control Validation
-
-      - Implement role-based access control (RBAC) with the principle of least privilege. No user or service account gets more access than required.
-      - Define access control matrices mapping roles to resources and operations. Review and update quarterly.
-      - Enforce multi-factor authentication (MFA) for all administrative and privileged access.
-      - Automate access reviews: flag dormant accounts (no login in 90 days), over-provisioned roles, and orphaned service accounts.
-      - Log all access control changes (role assignments, permission grants, policy updates) with who-changed-what-when detail.
-      - Test access controls with negative tests: verify that unauthorized roles are denied, not just that authorized roles succeed.
-
-  - id: change-management
-    tier: recommended
-    title: "Change Management & Audit Trail"
-    content: |
-      ## Change Management & Audit Trail
-
-      - Every production change requires a documented change request with description, risk assessment, rollback plan, and approval.
-      - Enforce separation of duties: the person who writes code cannot be the sole approver for deployment.
-      - Maintain an immutable audit trail of all changes: code commits, config changes, infrastructure modifications, access grants.
-      - Implement automated change detection: alert on unexpected file changes, config drift, or unauthorized deployments.
-      - Conduct post-incident reviews for all unplanned changes. Document root cause, timeline, and preventive measures.
-      - Tag all deployments with version, timestamp, deployer, and change request ID for full traceability.
-
-  - id: incident-response
-    tier: recommended
-    title: "Incident Response Procedures"
-    content: |
-      ## Incident Response Procedures
-
-      - Define and document an incident response plan with clear roles: incident commander, communications lead, technical lead.
-      - Classify incidents by severity (P1-P4) with defined response times, escalation paths, and communication templates.
-      - Implement automated incident detection: anomaly alerts, threshold breaches, security event correlation.
-      - Conduct tabletop exercises quarterly to test incident response procedures with realistic scenarios.
-      - Maintain a post-mortem culture: blameless retrospectives within 48 hours, action items tracked to completion.
-      - Ensure incident logs are retained for SOC2 audit periods (minimum 12 months) with tamper-evident storage.
+tag: SOC2
+section: instructions
+blocks:
+  - id: access-control-validation
+    tier: recommended
+    title: "Access Control Validation"
+    content: |
+      ## Access Control Validation
+
+      - Implement role-based access control (RBAC) with the principle of least privilege. No user or service account gets more access than required.
+      - Define access control matrices mapping roles to resources and operations. Review and update quarterly.
+      - Enforce multi-factor authentication (MFA) for all administrative and privileged access.
+      - Automate access reviews: flag dormant accounts (no login in 90 days), over-provisioned roles, and orphaned service accounts.
+      - Log all access control changes (role assignments, permission grants, policy updates) with who-changed-what-when detail.
+      - Test access controls with negative tests: verify that unauthorized roles are denied, not just that authorized roles succeed.
+
+  - id: change-management
+    tier: recommended
+    title: "Change Management & Audit Trail"
+    content: |
+      ## Change Management & Audit Trail
+
+      - Every production change requires a documented change request with description, risk assessment, rollback plan, and approval.
+      - Enforce separation of duties: the person who writes code cannot be the sole approver for deployment.
+      - Maintain an immutable audit trail of all changes: code commits, config changes, infrastructure modifications, access grants.
+      - Implement automated change detection: alert on unexpected file changes, config drift, or unauthorized deployments.
+      - Conduct post-incident reviews for all unplanned changes. Document root cause, timeline, and preventive measures.
+      - Tag all deployments with version, timestamp, deployer, and change request ID for full traceability.
+
+  - id: incident-response
+    tier: recommended
+    title: "Incident Response Procedures"
+    content: |
+      ## Incident Response Procedures
+
+      - Define and document an incident response plan with clear roles: incident commander, communications lead, technical lead.
+      - Classify incidents by severity (P1-P4) with defined response times, escalation paths, and communication templates.
+      - Implement automated incident detection: anomaly alerts, threshold breaches, security event correlation.
+      - Conduct tabletop exercises quarterly to test incident response procedures with realistic scenarios.
+      - Maintain a post-mortem culture: blameless retrospectives within 48 hours, action items tracked to completion.
+      - Ensure incident logs are retained for SOC2 audit periods (minimum 12 months) with tamper-evident storage.

package/templates/soc2/mcp-servers.yaml

@@ -1,24 +1,24 @@
-tag: SOC2
-section: mcp-servers
-servers:
-  - name: github
-    description: "GitHub repository management — PR reviews, access controls, audit trails for change management"
-    command: npx
-    args: ["-y", "@modelcontextprotocol/server-github"]
-    tags: [SOC2, UNIVERSAL]
-    category: version-control
-    tier: recommended
-    env:
-      GITHUB_PERSONAL_ACCESS_TOKEN: ""
-    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/github"
-
-  - name: sentry
-    description: "Sentry error and incident tracking — incident response monitoring and alerting"
-    command: npx
-    args: ["-y", "mcp-server-sentry"]
-    tags: [SOC2, API]
-    category: monitoring
-    tier: optional
-    env:
-      SENTRY_AUTH_TOKEN: ""
-    url: "https://github.com/modelcontextprotocol/servers"
+tag: SOC2
+section: mcp-servers
+servers:
+  - name: github
+    description: "GitHub repository management — PR reviews, access controls, audit trails for change management"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-github"]
+    tags: [SOC2, UNIVERSAL]
+    category: version-control
+    tier: recommended
+    env:
+      GITHUB_PERSONAL_ACCESS_TOKEN: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/github"
+
+  - name: sentry
+    description: "Sentry error and incident tracking — incident response monitoring and alerting"
+    command: npx
+    args: ["-y", "mcp-server-sentry"]
+    tags: [SOC2, API]
+    category: monitoring
+    tier: optional
+    env:
+      SENTRY_AUTH_TOKEN: ""
+    url: "https://github.com/modelcontextprotocol/servers"

package/templates/social/instructions.yaml

@@ -1,43 +1,43 @@
-tag: SOCIAL
-section: instructions
-blocks:
-  - id: ugc-moderation
-    tier: recommended
-    title: "User-Generated Content & Moderation"
-    content: |
-      ## User-Generated Content & Moderation
-
-      - Treat all user-generated content (UGC) as untrusted input. Sanitize HTML, validate file types and sizes, and strip EXIF metadata from uploaded images to prevent data leakage.
-      - Implement a multi-layer moderation pipeline: automated filters (keyword blocklists, ML classifiers) → queue for human review → final disposition (approve, reject, escalate).
-      - Use a content status model: all UGC transitions through states (pending → approved / rejected / flagged). Only approved content is visible to other users by default.
-      - Implement user-driven reporting with structured categories (spam, harassment, misinformation, illegal content). Deduplicate reports and escalate based on volume and severity.
-      - Apply rate limiting on content creation: new accounts should have stricter limits (e.g., max 5 posts/day) that relax as the account ages and builds trust.
-      - Maintain appeal workflows: users whose content is removed should be notified with the reason and given a clear path to appeal the decision.
-      - Log all moderation actions (who, what, when, why) for accountability and to train automated classifiers over time.
-
-  - id: feeds-notifications
-    tier: recommended
-    title: "Feeds & Notification Systems"
-    content: |
-      ## Feed Generation & Notifications
-
-      - Use a fan-out-on-write strategy for small-to-medium scale: when a user posts, push the post ID to each follower's feed cache (e.g., Redis sorted set by timestamp).
-      - For high-follower accounts (celebrities), use fan-out-on-read: merge their posts into the feed at read time to avoid writing to millions of follower feeds.
-      - Implement cursor-based pagination for feeds (`?after=<post_id>&limit=20`). Never use offset-based pagination—it produces inconsistent results as new content is inserted.
-      - Separate notification delivery from notification generation. Generate notifications as events, then deliver them through multiple channels (in-app, push, email) based on user preferences.
-      - Batch and debounce notifications to avoid spamming: "5 people liked your post" rather than 5 individual notifications within a minute.
-      - Store notification read/unread state per user. Provide a "mark all as read" endpoint and support real-time badge count updates via WebSocket or SSE.
-
-  - id: privacy-social-graph
-    tier: recommended
-    title: "Privacy & Social Graph"
-    content: |
-      ## Privacy Controls & Social Graph
-
-      - Default to private. New accounts should have restrictive visibility settings that users explicitly open up, not the reverse.
-      - Model privacy as a per-resource, per-audience policy: each piece of content can be visible to `public`, `followers`, `mutual_follows`, `specific_list`, or `only_me`.
-      - Enforce privacy at the data access layer (query filters), not just the UI. A direct API call with a content ID must still respect the viewer's permission relative to the content owner.
-      - Support account blocking and muting as first-class features. Blocked users cannot view the blocker's content, send messages, or appear in their feeds—enforced server-side.
-      - Store the social graph (follow/friend relationships) in a structure optimized for common queries: "does A follow B?" (O(1) lookup), "who does A follow?" (paginated list), "mutual friends of A and B" (set intersection).
-      - Implement data export (GDPR Article 20) and account deletion (GDPR Article 17) as automated, auditable processes. Deletion must cascade to all content, messages, and derived data.
-      - Rate-limit follow/friend actions to prevent spam following. Detect and flag accounts exhibiting bot-like social graph manipulation patterns.
+tag: SOCIAL
+section: instructions
+blocks:
+  - id: ugc-moderation
+    tier: recommended
+    title: "User-Generated Content & Moderation"
+    content: |
+      ## User-Generated Content & Moderation
+
+      - Treat all user-generated content (UGC) as untrusted input. Sanitize HTML, validate file types and sizes, and strip EXIF metadata from uploaded images to prevent data leakage.
+      - Implement a multi-layer moderation pipeline: automated filters (keyword blocklists, ML classifiers) → queue for human review → final disposition (approve, reject, escalate).
+      - Use a content status model: all UGC transitions through states (pending → approved / rejected / flagged). Only approved content is visible to other users by default.
+      - Implement user-driven reporting with structured categories (spam, harassment, misinformation, illegal content). Deduplicate reports and escalate based on volume and severity.
+      - Apply rate limiting on content creation: new accounts should have stricter limits (e.g., max 5 posts/day) that relax as the account ages and builds trust.
+      - Maintain appeal workflows: users whose content is removed should be notified with the reason and given a clear path to appeal the decision.
+      - Log all moderation actions (who, what, when, why) for accountability and to train automated classifiers over time.
+
+  - id: feeds-notifications
+    tier: recommended
+    title: "Feeds & Notification Systems"
+    content: |
+      ## Feed Generation & Notifications
+
+      - Use a fan-out-on-write strategy for small-to-medium scale: when a user posts, push the post ID to each follower's feed cache (e.g., Redis sorted set by timestamp).
+      - For high-follower accounts (celebrities), use fan-out-on-read: merge their posts into the feed at read time to avoid writing to millions of follower feeds.
+      - Implement cursor-based pagination for feeds (`?after=<post_id>&limit=20`). Never use offset-based pagination—it produces inconsistent results as new content is inserted.
+      - Separate notification delivery from notification generation. Generate notifications as events, then deliver them through multiple channels (in-app, push, email) based on user preferences.
+      - Batch and debounce notifications to avoid spamming: "5 people liked your post" rather than 5 individual notifications within a minute.
+      - Store notification read/unread state per user. Provide a "mark all as read" endpoint and support real-time badge count updates via WebSocket or SSE.
+
+  - id: privacy-social-graph
+    tier: recommended
+    title: "Privacy & Social Graph"
+    content: |
+      ## Privacy Controls & Social Graph
+
+      - Default to private. New accounts should have restrictive visibility settings that users explicitly open up, not the reverse.
+      - Model privacy as a per-resource, per-audience policy: each piece of content can be visible to `public`, `followers`, `mutual_follows`, `specific_list`, or `only_me`.
+      - Enforce privacy at the data access layer (query filters), not just the UI. A direct API call with a content ID must still respect the viewer's permission relative to the content owner.
+      - Support account blocking and muting as first-class features. Blocked users cannot view the blocker's content, send messages, or appear in their feeds—enforced server-side.
+      - Store the social graph (follow/friend relationships) in a structure optimized for common queries: "does A follow B?" (O(1) lookup), "who does A follow?" (paginated list), "mutual friends of A and B" (set intersection).
+      - Implement data export (GDPR Article 20) and account deletion (GDPR Article 17) as automated, auditable processes. Deletion must cascade to all content, messages, and derived data.
+      - Rate-limit follow/friend actions to prevent spam following. Detect and flag accounts exhibiting bot-like social graph manipulation patterns.

package/templates/social/mcp-servers.yaml

@@ -1,24 +1,24 @@
-tag: SOCIAL
-section: mcp-servers
-servers:
-  - name: postgres
-    description: "PostgreSQL database inspection, queries, and schema management — common backend for social platforms"
-    command: npx
-    args: ["-y", "@modelcontextprotocol/server-postgres"]
-    tags: [DATA-PIPELINE, API, SOCIAL]
-    category: database
-    tier: recommended
-    env:
-      POSTGRES_CONNECTION_STRING: ""
-    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"
-
-  - name: redis
-    description: "Redis key-value store management — caching, sessions, feeds, and real-time features"
-    command: npx
-    args: ["-y", "mcp-server-redis"]
-    tags: [REALTIME, SOCIAL]
-    category: database
-    tier: optional
-    env:
-      REDIS_URL: "redis://localhost:6379"
-    url: "https://github.com/nicholasgriffintn/redis-mcp-server"
+tag: SOCIAL
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection, queries, and schema management — common backend for social platforms"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [DATA-PIPELINE, API, SOCIAL]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"
+
+  - name: redis
+    description: "Redis key-value store management — caching, sessions, feeds, and real-time features"
+    command: npx
+    args: ["-y", "mcp-server-redis"]
+    tags: [REALTIME, SOCIAL]
+    category: database
+    tier: optional
+    env:
+      REDIS_URL: "redis://localhost:6379"
+    url: "https://github.com/nicholasgriffintn/redis-mcp-server"

package/templates/state-machine/instructions.yaml

@@ -1,42 +1,42 @@
-tag: STATE-MACHINE
-section: instructions
-blocks:
-  - id: state-transition-design
-    tier: recommended
-    title: "State Transition Design"
-    content: |
-      ## State Transition Patterns
-
-      - Define all valid states and transitions as an explicit, declarative configuration (object map, table, or DSL)—never as scattered if/else chains across the codebase.
-      - Make the state machine the single source of truth for "what can happen next." UI elements, API validations, and business logic should all derive their behavior from the machine definition.
-      - Every transition should be triggered by a named event. Use past-tense names for events that report something happened (`PAYMENT_RECEIVED`) and imperative names for commands (`SUBMIT_ORDER`).
-      - Model transitions as pure functions: `(currentState, event) → nextState + effects`. Keep the transition logic free of side effects; execute effects (API calls, notifications) separately.
-      - Validate transitions before executing them. If an event is not valid in the current state, reject it with a clear error rather than silently ignoring it.
-      - Persist the current state and a history of transitions (event, from-state, to-state, timestamp, actor) for auditability and debugging.
-      - Visualize the state machine from its definition (e.g., generate a Mermaid or Graphviz diagram). Review the diagram in PRs that modify state logic.
-
-  - id: guards-actions
-    tier: recommended
-    title: "Guards, Actions & Side Effects"
-    content: |
-      ## Guards, Actions & Side Effects
-
-      - Use guard conditions to make transitions conditional: a transition fires only if the guard predicate evaluates to true given the current context.
-      - Keep guards as pure, synchronous predicates. If a guard needs async data, fetch the data before sending the event to the machine—don't make the machine wait on I/O.
-      - Separate actions into three categories: entry actions (run when entering a state), exit actions (run when leaving a state), and transition actions (run during a specific transition).
-      - Actions should be fire-and-forget from the machine's perspective. If an action can fail and the failure matters, model the failure as a new event that the machine handles.
-      - Use the context (extended state) to carry data that influences guards and actions. Update context immutably during transitions to maintain a clear audit trail.
-      - Implement an effect/service layer that the machine invokes but does not depend on directly. This makes the machine testable in isolation without mocking external systems.
-
-  - id: hierarchical-parallel
-    tier: recommended
-    title: "Hierarchical & Parallel States"
-    content: |
-      ## Hierarchical & Parallel State Patterns
-
-      - Use hierarchical (nested) states to avoid transition explosion. Common behaviors shared by sibling states should be defined on the parent state.
-      - Model independent concurrent behaviors as parallel (orthogonal) state regions. For example, a form component might have parallel regions for validation state and submission state.
-      - Define clear entry and exit points for compound states. Use initial states for child regions and final states to signal region completion.
-      - Avoid deeply nested hierarchies (> 3 levels). If nesting grows complex, consider decomposing into separate communicating machines via the actor model.
-      - Use `done` events to coordinate between parallel regions or between parent and child machines. A parent can transition when all child regions reach their final states.
-      - Test state machines exhaustively: cover every state, every transition, every guard branch, and every unreachable-state assertion. Use model-based testing to auto-generate transition paths.
+tag: STATE-MACHINE
+section: instructions
+blocks:
+  - id: state-transition-design
+    tier: recommended
+    title: "State Transition Design"
+    content: |
+      ## State Transition Patterns
+
+      - Define all valid states and transitions as an explicit, declarative configuration (object map, table, or DSL)—never as scattered if/else chains across the codebase.
+      - Make the state machine the single source of truth for "what can happen next." UI elements, API validations, and business logic should all derive their behavior from the machine definition.
+      - Every transition should be triggered by a named event. Use past-tense names for events that report something happened (`PAYMENT_RECEIVED`) and imperative names for commands (`SUBMIT_ORDER`).
+      - Model transitions as pure functions: `(currentState, event) → nextState + effects`. Keep the transition logic free of side effects; execute effects (API calls, notifications) separately.
+      - Validate transitions before executing them. If an event is not valid in the current state, reject it with a clear error rather than silently ignoring it.
+      - Persist the current state and a history of transitions (event, from-state, to-state, timestamp, actor) for auditability and debugging.
+      - Visualize the state machine from its definition (e.g., generate a Mermaid or Graphviz diagram). Review the diagram in PRs that modify state logic.
+
+  - id: guards-actions
+    tier: recommended
+    title: "Guards, Actions & Side Effects"
+    content: |
+      ## Guards, Actions & Side Effects
+
+      - Use guard conditions to make transitions conditional: a transition fires only if the guard predicate evaluates to true given the current context.
+      - Keep guards as pure, synchronous predicates. If a guard needs async data, fetch the data before sending the event to the machine—don't make the machine wait on I/O.
+      - Separate actions into three categories: entry actions (run when entering a state), exit actions (run when leaving a state), and transition actions (run during a specific transition).
+      - Actions should be fire-and-forget from the machine's perspective. If an action can fail and the failure matters, model the failure as a new event that the machine handles.
+      - Use the context (extended state) to carry data that influences guards and actions. Update context immutably during transitions to maintain a clear audit trail.
+      - Implement an effect/service layer that the machine invokes but does not depend on directly. This makes the machine testable in isolation without mocking external systems.
+
+  - id: hierarchical-parallel
+    tier: recommended
+    title: "Hierarchical & Parallel States"
+    content: |
+      ## Hierarchical & Parallel State Patterns
+
+      - Use hierarchical (nested) states to avoid transition explosion. Common behaviors shared by sibling states should be defined on the parent state.
+      - Model independent concurrent behaviors as parallel (orthogonal) state regions. For example, a form component might have parallel regions for validation state and submission state.
+      - Define clear entry and exit points for compound states. Use initial states for child regions and final states to signal region completion.
+      - Avoid deeply nested hierarchies (> 3 levels). If nesting grows complex, consider decomposing into separate communicating machines via the actor model.
+      - Use `done` events to coordinate between parallel regions or between parent and child machines. A parent can transition when all child regions reach their final states.
+      - Test state machines exhaustively: cover every state, every transition, every guard branch, and every unreachable-state assertion. Use model-based testing to auto-generate transition paths.

package/templates/state-machine/mcp-servers.yaml

@@ -1,11 +1,11 @@
-tag: STATE-MACHINE
-section: mcp-servers
-servers:
-  - name: sequential-thinking
-    description: "Dynamic, reflective problem-solving through thought sequences — ideal for modeling state transitions"
-    command: npx
-    args: ["-y", "@modelcontextprotocol/server-sequential-thinking"]
-    tags: [UNIVERSAL, STATE-MACHINE]
-    category: general
-    tier: optional
-    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking"
+tag: STATE-MACHINE
+section: mcp-servers
+servers:
+  - name: sequential-thinking
+    description: "Dynamic, reflective problem-solving through thought sequences — ideal for modeling state transitions"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-sequential-thinking"]
+    tags: [UNIVERSAL, STATE-MACHINE]
+    category: general
+    tier: optional
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking"