Record comprehensive implementation details for a completed task. ⚠️ CRITICAL: Artifacts are REQUIRED. This creates a searchable knowledge base that future AI agents use to discover existing code and avoid duplication. WHY DETAILED LOGGING MATTERS Future AI agents (and future you) will use grep/r...
Risk signalsHigh parameter count (15 properties)
Part of the Spec Workflow server.
Free to start. No card required.
AI agents may call log-implementation to permanently remove or destroy resources in Spec Workflow. Without a policy, an autonomous agent could delete critical data in a loop with no way to undo the damage. PolicyLayer blocks destructive tools by default and requires explicit human approval before enabling them.
Without a policy, an AI agent could call log-implementation in a loop, permanently destroying resources in Spec Workflow. There is no undo for destructive operations. PolicyLayer blocks this tool by default and only allows it when a human explicitly approves the action.
Destructive tools permanently remove data. Block by default. Only enable with explicit approval workflows.
{
"version": "1",
"default": "deny",
"hide": [
"log-implementation"
]
}See the full Spec Workflow policy for all 5 tools.
These attack patterns abuse exactly the kind of access log-implementation gives an agent. Each links to the full case and the policy that stops it:
Other destructive tools across the catalogue. The same approach applies to each: deny by default, or require human approval.
Record comprehensive implementation details for a completed task. ⚠️ CRITICAL: Artifacts are REQUIRED. This creates a searchable knowledge base that future AI agents use to discover existing code and avoid duplication. WHY DETAILED LOGGING MATTERS Future AI agents (and future you) will use grep/ripgrep to search implementation logs before implementing new tasks. Complete logs prevent: - ❌ Creating duplicate API endpoints - ❌ Reimplementing existing components - ❌ Duplicating utility functions and business logic - ❌ Breaking established integration patterns Incomplete logs = Duplicated code = Technical debt REQUIRED FIELDS artifacts (REQUIRED - Object) Contains structured data about what was implemented. Must include relevant artifact types: apiEndpoints (array of API endpoint objects) When new API endpoints are created/modified, document: - method: HTTP method (GET, POST, PUT, DELETE, PATCH) - path: Route path (e.g., "/api/specs/:name/logs") - purpose: What this endpoint does - requestFormat: Request body/query params format (JSON schema or example) - responseFormat: Response structure (JSON schema or example) - location: File path and line number (e.g., "src/server.ts:245") Example: { "method": "GET", "path": "/api/specs/:name/implementation-log", "purpose": "Retrieve implementation logs with optional filtering", "requestFormat": "Query params: taskId (string, optional), search (string, optional)", "responseFormat": "{ entries: ImplementationLogEntry[] }", "location": "src/dashboard/server.ts:245" } components (array of component objects) When reusable UI components are created, document: - name: Component name - type: Framework type (React, Vue, Svelte, etc.) - purpose: What the component does - location: File path - props: Props interface or type signature - exports: What it exports (array of export names) Example: { "name": "LogsPage", "type": "React", "purpose": "Main dashboard page for viewing implementation logs with search and filtering", "location": "src/modules/pages/LogsPage.tsx", "props": "{ specs: any[], selectedSpec: string, onSelect: (value: string) => void }", "exports": ["LogsPage (default)"] } functions (array of function objects) When utility functions are created, document: - name: Function name - purpose: What it does - location: File path and line - signature: Function signature (params and return type) - isExported: Whether it can be imported Example: { "name": "searchLogs", "purpose": "Search implementation logs by keyword", "location": "src/dashboard/implementation-log-manager.ts:156", "signature": "(searchTerm: string) => Promise<ImplementationLogEntry[]>", "isExported": true } classes (array of class objects) When classes are created, document: - name: Class name - purpose: What the class does - location: File path - methods: List of public methods - isExported: Whether it can be imported Example: { "name": "ImplementationLogManager", "purpose": "Manages CRUD operations for implementation logs", "location": "src/dashboard/implementation-log-manager.ts", "methods": ["loadLog", "addLogEntry", "getAllLogs", "searchLogs", "getTaskStats"], "isExported": true } integrations (array of integration objects) Document how frontend connects to backend: - description: How components connect to APIs - frontendComponent: Which component initiates the connection - backendEndpoint: Which API endpoint is called - dataFlow: Describe the data flow (e.g., "User clicks → API call → State update → Re-render") Example: { "description": "LogsPage fetches logs via REST API and subscribes to WebSocket for real-time updates", "frontendComponent": "LogsPage", "backendEndpoint": "GET /api/specs/:name/implementation-log", "dataFlow": "Component mount → API fetch → Display logs → WebSocket subscription → Real-time updates on new entries" } GOOD EXAMPLE (Include ALL relevant artifacts) Task: "Implemented logs dashboard with real-time updates" json { "taskId": "2.3", "summary": "Implemented real-time implementation logs dashboard with filtering, search, and WebSocket updates", "artifacts": { "apiEndpoints": [ { "method": "GET", "path": "/api/specs/:name/implementation-log", "purpose": "Retrieve implementation logs with optional filtering", "requestFormat": "Query params: taskId (string, optional), search (string, optional)", "responseFormat": "{ entries: ImplementationLogEntry[] }", "location": "src/dashboard/server.ts:245" } ], "components": [ { "name": "LogsPage", "type": "React", "purpose": "Main dashboard page for viewing implementation logs with search and filtering", "location": "src/modules/pages/LogsPage.tsx", "props": "None (uses React Router params)", "exports": ["LogsPage (default)"] } ], "classes": [ { "name": "ImplementationLogManager", "purpose": "Manages CRUD operations for implementation logs", "location": "src/dashboard/implementation-log-manager.ts", "methods": ["loadLog", "addLogEntry", "getAllLogs", "searchLogs", "getTaskStats"], "isExported": true } ], "integrations": [ { "description": "LogsPage fetches logs via REST API and subscribes to WebSocket for real-time updates", "frontendComponent": "LogsPage", "backendEndpoint": "GET /api/specs/:name/implementation-log", "dataFlow": "Component mount → API fetch → Display logs → WebSocket subscription → Real-time updates on new entries" } ] }, "filesModified": ["src/dashboard/server.ts"], "filesCreated": ["src/modules/pages/LogsPage.tsx"], "statistics": { "linesAdded": 650, "linesRemoved": 15, "filesChanged": 2 } } BAD EXAMPLE (Don't do this) ❌ Empty artifacts - Future agents learn nothing: json { "taskId": "2.3", "summary": "Added endpoint and page", "artifacts": {}, "filesModified": ["server.ts"], "filesCreated": ["LogsPage.tsx"] } ❌ Vague summary with no structured data: json { "taskId": "2.3", "summary": "Implemented features", "artifacts": {}, "filesModified": ["server.ts", "app.tsx"] } Instructions 1. After completing a task, review what you implemented 2. Identify all artifacts (APIs, components, functions, classes, integrations) 3. Document each with full details and locations 4. Include ALL the information - be thorough! 5. Future agents depend on this data quality. It is categorised as a Destructive tool in the Spec Workflow MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
Register the Spec Workflow MCP server in PolicyLayer and add a rule for log-implementation: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Spec Workflow. Nothing to install.
log-implementation is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the log-implementation rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for log-implementation. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
log-implementation is provided by the Spec Workflow MCP server (@pimzino/spec-workflow-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 5 Spec Workflow tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.