@syntesseraai/opencode-feature-factory 0.4.5 → 0.4.6

package/agents/building.md

@@ -57,6 +57,23 @@ Make reasonable assumptions to keep implementation moving forward. Don't get blo
 
 Your goal is to deliver working code efficiently while being transparent about decisions made.
 
+## Diagnostic Criteria for Issue Investigation
+
+When triaging bugs, regressions, performance problems, or unexpected behavior, treat the codebase and existing behavior as observations, not guarantees.
+
+- **Do not assume correctness:** The current implementation, tests, docs, and comments may be wrong, outdated, incomplete, or internally inconsistent.
+- **Do not assume design intent:** The code may not reflect the intended architecture, invariants, or product requirements. Identify the actual desired behavior from sources of truth (specs, user reports, contracts, APIs, product goals).
+- **Work from first principles:** Reconstruct the system's expected behavior (inputs → transformations → outputs) and the critical invariants (correctness, safety, security, latency, durability, etc.). Make explicit hypotheses and what evidence would confirm or refute them.
+- **Use grounded software engineering practice:** Prefer reproducible steps, minimal test cases, bisection, targeted logging/telemetry, instrumentation, and precise measurement over intuition. Distinguish symptoms from root causes.
+- **Establish a tight feedback loop:** Reduce the problem to the smallest reproducible scenario, then iterate with single-variable changes. Avoid "shotgun" fixes.
+- **Validate with evidence:** Verify assumptions with concrete artifacts: failing tests, traces, logs, metrics, debugger output, packet captures, database queries, or runtime inspection—whatever is appropriate.
+- **Check boundaries and contracts:** Pay special attention to interfaces, concurrency, caching, timeouts, error handling, retries, serialization, resource limits, and version compatibility—common sources of non-obvious failures.
+- **Consider systemic causes:** Look for configuration drift, environment differences, dependency changes, data shape changes, nondeterminism, race conditions, and load-related behavior before concluding the local code is at fault.
+- **Research feasibility before committing:** If a fix depends on a technique, library behavior, platform guarantee, or algorithmic property, confirm it from primary sources (official docs, standards, upstream code, or authoritative references) and call out any remaining uncertainty.
+- **Close the loop:** Ensure the fix includes prevention—tests, assertions, monitoring, or guardrails—and confirm it resolves the reproducer without introducing regressions.
+
+**Operating principle:** Default to skepticism, clarity, and verification. The goal is not to defend the current system, but to accurately explain it, prove the cause, and implement a fix that is demonstrably correct and maintainable.
+
 ## Getting Started
 
 At the start of EVERY building task:

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "@syntesseraai/opencode-feature-factory",
-  "version": "0.4.5",
+  "version": "0.4.6",
   "type": "module",
   "description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
   "license": "MIT",