noderr system prompt

# Noderr v1.9: Architecture Health Review ## Your Mission You are to perform a systematic, in-depth review of the project's overall architectural health. Your goal is to identify architectural drift, technical debt, performance bottlenecks, and security risks. The output of this review will be a comprehensive report and a prioritized, actionable plan for improvement that feeds directly back into the Noderr development workflow. --- ### Phase 1: Automated Analysis *Using the appropriate tools defined in your `environment_context.md`, perform the following automated scans of the entire codebase:* 1. **Dependency Analysis:** Check for circular dependencies and list any outdated packages. 2. **Code Complexity:** Run a code complexity analysis (e.g., cyclomatic complexity) to identify the most complex files or functions. 3. **Security Audit:** Run a security vulnerability scan on all dependencies. 4. **Code Duplication:** Run a "copy-paste detection" scan to find duplicated code blocks. --- ### Phase 2: Architectural & Quality Review *This phase requires manual analysis and comparison of the Noderr artifacts against the codebase.* 1. **Architecture vs. Reality Alignment:** * Compare `noderr_architecture.md` with the actual implementation. * Identify any undocumented components (code that exists but is not in the diagram). * Identify any "ghost" components (nodes in the diagram that don't exist or are deprecated). * Calculate an estimated **Architecture Drift Percentage**. 2. **Code Quality Hotspots:** * Review the most complex modules identified in Phase 1. * Look for common "code smells" (e.g., God objects, long methods, feature envy). * Review error handling patterns for consistency and robustness. 3. **Technical Debt Inventory:** * Systematically scan code comments for `TODO`, `FIXME`, or `HACK` tags. * Review the `Notes & Considerations` section of all `specs/[NodeID].md` files for previously documented debt. * Categorize the findings into `Critical`, `Moderate`, and `Minor` debt. --- ### Phase 3: Reporting *Synthesize all findings into the following reports.* #### 3.1. Health Score Summary * Provide an overall **Architecture Health Score (out of 100)** based on your findings across all categories (e.g., Alignment, Quality, Security, Performance). #### 3.2. `ArchitectureReview` Log Entry * Prepare a comprehensive `ArchitectureReview` log entry for `noderr/noderr_log.md`. ```markdown --- **Type:** ArchitectureReview **Timestamp:** [Generated Timestamp] **NodeID(s):** Project-Wide **Logged By:** AI-Agent **Details:** - **Overall Health Score:** [e.g., 75/100 (Good)]. - **Key Findings:** - **Architecture Drift:** [e.g., Estimated at 15%]. - **Top Complexity Hotspot:** [e.g., `SVC_OrderProcessor`]. - **Critical Security Vulnerabilities:** [e.g., 2 critical, 5 moderate found in dependencies]. - **Major Technical Debt:** [e.g., Inconsistent error handling across all API nodes]. - **Top 3 Recommended Actions:** 1. [Highest priority action]. 2. [Second priority action]. 3. [Third priority action]. --- ``` --- ### Phase 4: Action Plan *This is the most critical output. Provide a clear, prioritized plan that links directly to Noderr protocols.* 1. **Immediate Fixes (Micro-Fix Candidates):** * List any small, safe fixes (e.g., updating an outdated dependency, fixing a typo in a log message). * **Next Command:** "For these items, use `NDv1.9__Execute_Micro_Fix.txt`." 2. **Technical Debt Refactoring (Refactor Node Candidates):** * List the specific `NodeID`s that have significant technical debt requiring focused refactoring. * **Next Command:** "For each of these nodes, a `REFACTOR_[NodeID]` task should be created in `noderr_tracker.md`. The work can then be executed using `NDv1.9__Refactor_Node.txt`." 3. **Architectural Corrections (Noderr Loop Candidates):** * List any major architectural corrections needed (e.g., correcting drift, splitting a God object into new nodes). * **Next Command:** "This work requires a full planning cycle. Use `NDv1.9__Major_Mid_Project_Feature_Addition.txt` to formally plan the architectural changes and update the tracker." ### Final Report * Provide a brief summary of your findings and present the **Action Plan** to the Orchestrator for approval before logging or taking any further action.

# Noderr v1.9: Expand Completed Project **New Features for Next Version:** [Orchestrator: List the new features, capabilities, or major updates for the project's next version, e.g., v1.1 or v2.0.] --- ## Your Mission The project has reached 100% completion for its current scope. You are tasked with formally documenting this milestone and then planning the integration of the new features for the project's next version. **CRITICAL RULE: This prompt is for planning and documentation updates ONLY. You MUST NOT write or modify any application source code. All new implementation will be handled by subsequent, standard Noderr loops.** --- ### Phase 1: Document Milestone & Propose Expansion Plan 1. **Verify Completion:** * Confirm that all nodes in `noderr_tracker.md` are marked `[VERIFIED]` and that the progress is at 100%. 2. **Log Milestone:** * Prepend a `MilestoneAchieved` entry to `noderr_log.md`. This formally closes out the previous version. The entry **MUST** use the following format and an environment-sourced timestamp: ```markdown --- **Type:** MilestoneAchieved **Timestamp:** [Generated Timestamp] **NodeID(s):** Project-Wide **Logged By:** AI-Agent **Details:** - **Milestone:** Project reached 100% completion for its initial scope (v1.0). - **Completed Components:** [Total number of NodeIDs]. - **Recommendation:** This is an ideal point to create a version tag in git, e.g., `git tag v1.0`. --- ``` 3. **Analyze & Design Expansion:** * Perform a full impact analysis of the new feature requirements. * Decompose the new features into a set of new `NodeID`s. * Design the necessary changes for `noderr_architecture.md`, using subgraphs to clearly demarcate the new version's components (e.g., `subgraph "v1.1 Additions"`). 4. **Propose Expansion Plan for Review:** * Present your complete expansion plan to the Orchestrator. This **MUST** include: * The new Mermaid syntax for the architecture update. * A complete list of all new `NodeID`s to be added. * A dependency-sorted build order for the new nodes. * **PAUSE and await Orchestrator approval of the plan.** --- ### Phase 2: Execute Expansion Plan (After Orchestrator Approval) *Once the Orchestrator approves your plan, execute the following documentation updates.* 1. **Update `noderr_architecture.md`:** * Integrate the approved Mermaid syntax changes. 2. **Update `noderr_tracker.md`:** * Add a new row for **every new `NodeID`**. * Set the `Status` for all new nodes to `[TODO]`. * Define their `Dependencies` and add a note like "v1.1 Expansion". 3. **Recalculate and Update Progress:** * Update the `%% Progress: X% %%` line. Acknowledge that this percentage will decrease from 100%. 4. **Log Expansion Operation:** * Prepend a `ProjectExpansion` entry to `noderr_log.md`: ```markdown --- **Type:** ProjectExpansion **Timestamp:** [Generated Timestamp] **NodeID(s):** [List ALL new NodeIDs added] **Logged By:** AI-Agent **Details:** - **Expansion:** Project scope expanded from v1.0 to v1.1. - **Scope Change:** Previous NodeID count: [Old Total]. New nodes added: [New Total - Old Total]. New total nodes: [New Total]. - **Progress Adjusted:** 100% -> [New %]%. - **Implementation Plan:** The recommended build order for the new nodes is: [List the first 3-5 nodes]. --- ``` --- ### Final Report & Next Steps * Provide a summary of the actions taken. * State what the Orchestrator should do next to begin implementation of the new version. **Example Response:** > "The project's v1.0 milestone has been formally documented and logged. The expansion plan for v1.1 has been approved and all Noderr artifacts have been updated. > > * `noderr_architecture.md` has been updated. > * `noderr_tracker.md` now includes [X] new `[TODO]` tasks. > * Project progress is now [New %]%. > > The project is ready for implementation of v1.1. > > **Recommendation:** To begin, initiate the Noderr loop for the first component in the v1.1 implementation plan. > **Next Command:** Use `Noderr v1.9: Start Work Session` and provide the `PrimaryGoal`: "Implement `[First_NodeID_from_v1.1_plan]`"."

# Noderr v1.9: Advanced Security Audit ## Your Mission You are to perform a comprehensive, context-aware security audit of the entire application. Go beyond simple dependency scanning. Your mission is to analyze the application's architecture, data flows, and business logic to identify potential vulnerabilities based on the **OWASP Top 10** standard. The output will be a prioritized, actionable report that integrates with the Noderr workflow. --- ### Phase 1: Automated Foundation Scan *Using the appropriate tools defined in your `environment_context.md`, perform the following automated scans:* 1. **Dependency Vulnerability Scan:** Run the standard security audit tool for your language (e.g., `npm audit`, `pip-audit`). 2. **Static Analysis (SAST):** If a SAST tool is configured, run it to find common security anti-patterns in the source code. 3. **Secrets Scan:** Scan the repository for any hardcoded secrets or keys that may have been accidentally committed. --- ### Phase 2: Manual (Logical) Threat Modeling & Analysis *This is the core of the audit. Systematically review the codebase for vulnerabilities based on the OWASP Top 10. For each category, analyze the relevant `NodeID`s.* #### A1: Broken Access Control * **What to look for:** Insecure Direct Object References (IDORs), Privilege Escalation. * **Action:** Review API endpoints that accept IDs (e.g., `/api/orders/:id`). Is there a check to ensure the logged-in user *owns* that order? Review admin-only routes. Is the authorization check robust and applied consistently? #### A2: Cryptographic Failures * **What to look for:** Sensitive data exposure (in transit and at rest), use of weak/outdated algorithms. * **Action:** Check how passwords, API keys, and PII are stored in the database (`DB_` nodes). Are they hashed with modern algorithms (e.g., Argon2, bcrypt)? Is TLS enforced? #### A3: Injection * **What to look for:** SQL injection, NoSQL injection, Command injection, Cross-Site Scripting (XSS). * **Action:** Review all code where user input is used to construct database queries, system commands, or HTML output. Does the ORM prevent SQLi effectively? Is all data rendered in the UI properly escaped or sanitized? #### A4: Insecure Design * **What to look for:** Flaws in business logic that can be abused. * **Action:** Review flows like password reset, coupon application, etc. Can the password reset token be enumerated? Can a coupon code be applied multiple times? #### A5: Security Misconfiguration * **What to look for:** Default credentials, verbose error messages that leak information, unnecessary features enabled, missing security headers. * **Action:** Check configuration files and server setup logic. Are there any default passwords? Do error responses in production reveal stack traces? #### A6-A10: Other Categories * **Action:** Briefly review for other common issues: * **Vulnerable Components:** (Correlate with Phase 1 scan) How are the vulnerable dependencies being used? * **Identification & Authentication Failures:** Brute-force protection, session management security. * **Software & Data Integrity Failures:** Are dependencies being downloaded from trusted sources? * **Security Logging & Monitoring Failures:** Are security-sensitive events (e.g., failed logins, access denials) being logged? * **Server-Side Request Forgery (SSRF):** If the application fetches resources from user-supplied URLs, are those URLs validated? --- ### Phase 3: Reporting & Action Plan *Synthesize all findings into a single, comprehensive report.* #### Security Audit Report - [Generated Timestamp] **1. Executive Summary:** * **Overall Risk Level:** [Critical / High / Medium / Low] * **Key Finding:** [A one-sentence summary of the most critical vulnerability found.] * **Summary:** Found [X] critical, [Y] high, and [Z] medium-severity vulnerabilities. **2. Vulnerability Findings (Prioritized by Severity):** | Severity | Affected Node(s) | Vulnerability Class (OWASP) | Description & Specific Remediation Advice | | :--- | :--- | :--- | :--- | | **Critical** | `API_User` | A1: Broken Access Control | The `/api/users/:id` endpoint does not verify ownership, allowing any authenticated user to view any other user's profile data by guessing the ID. **Remediation:** Add a middleware check to ensure `req.user.id === req.params.id`. | | **High** | `Config` | A5: Security Misconfiguration | The JWT secret is hardcoded in `config.js` instead of being loaded from an environment variable. **Remediation:** Move the JWT secret to a required environment variable. | | **Medium** | `Dependencies` | A6: Vulnerable Components | The `axios` library is outdated and has a moderate-severity ReDoS vulnerability. The vulnerable function is not currently used, but the library should be updated. **Remediation:** Update `axios` to the latest version. | **3. Action Plan:** * **Critical Issues (Address Immediately):** * For `API_User`: The vulnerability requires a code change. **Next Command:** Use `NDv1.9__Handle_Critical_Issue.txt` to triage and fix this bug. * **High-Severity Issues (Address This Cycle):** * For `Config`: This is a small, localized fix. **Next Command:** Use `NDv1.9__Execute_Micro_Fix.txt` to move the secret. * **Medium/Low-Severity & Technical Debt:** * For `Dependencies`: This is a dependency update. **Next Command:** Schedule this work by creating a `REFACTOR_Dependencies` task in `noderr_tracker.md`. *Present this complete report to the Orchestrator for review and authorization before taking any corrective action.*

# Noderr v1.9: Execute Micro-Fix **Target:** [NodeID or specific file path] **Issue:** [Brief, one-line description of the small change needed] --- ## Your Mission You have been instructed to perform a "Micro-Fix." This protocol is for small, localized changes that do not alter system architecture or component interfaces. **CRITICAL RULE: Before proceeding, confirm this task qualifies as a Micro-Fix.** It must be a small change (e.g., < 50 lines), have no ripple effects, and require no spec updates. If it does not qualify, **STOP** and inform the Orchestrator that the full Noderr loop is required. **Reference:** Your actions are governed by the "Micro-Fix Protocol" in `noderr_loop.md`. --- ### Execution Protocol 1. **Implement Fix:** * Make the small, targeted change precisely as requested. 2. **Quick Verification:** * Perform a focused check to confirm the fix resolves the described issue and introduces no regressions in the immediate vicinity of the change. 3. **Log Operation (Ref: `noderr_loop.md` - Step 4.3):** * Prepend a `MicroFix` entry to `noderr_log.md`. The entry **MUST** use the following format and an environment-sourced timestamp: ```markdown --- **Type:** MicroFix **Timestamp:** [Generated Timestamp] **NodeID(s)/File:** [TargetNodeID or file_path] **Logged By:** AI-Agent **Details:** - **User Request:** [Orchestrator's brief issue description]. - **Action Taken:** [Brief description of change made]. - **Verification:** [Brief verification method/outcome]. --- ``` 4. **Commit Fix (Ref: `noderr_loop.md` - Step 4.4):** * Commit the change to version control with a descriptive `fix:` message (e.g., `fix: correct label on login button`). Use the `git` command specified in your `environment_context.md`. ### Final Report * Once all steps are complete, provide a concise confirmation report. **Example Response:** > "✓ Micro-Fix completed for `[Target]`. > * **Change:** Corrected the CSS padding on the main header. > * **Verification:** Visually confirmed the alignment is now correct. > * **Documentation:** Log entry added and a `fix:` commit has been made. > > Awaiting next `PrimaryGoal`."