feat: add target repo examples and file layout guidance

examples/go-project/ai/harness-health.md

@@ -0,0 +1,13 @@
+# Harness Health
+
+- project map clarity: partial
+- validation commands: partial
+- fast feedback: weak
+- task templates: partial
+- guardrails: partial
+- doc-code alignment: partial
+
+## Top priorities
+1. Define repo-standard lint and test wrappers
+2. Document service dependencies for integration tests
+3. Clarify package ownership boundaries

examples/go-project/ai/project-map.md

@@ -0,0 +1,10 @@
+# Project Map
+
+## Main structure
+- `cmd/` contains runnable binaries
+- `internal/` contains non-exported app logic
+- `pkg/` is for reusable public packages if present
+
+## Notes
+- Check `Makefile` for repo-preferred command wrappers
+- Some integration tests may depend on Docker or local services

examples/go-project/ai/risk-guardrails.md

@@ -0,0 +1,6 @@
+# Risk Guardrails
+
+- Treat `cmd/` entrypoints and deployment wiring as high risk
+- Do not silently change interfaces consumed by other packages
+- Be careful with goroutines, channels, and context cancellation paths
+- Do not rewrite broad package layouts for a narrow bugfix

examples/go-project/ai/task-templates.md

@@ -0,0 +1,14 @@
+# Task Templates
+
+## Bugfix
+1. Read the affected package and nearby tests
+2. Explain root cause briefly
+3. Implement the smallest fix in the narrowest package possible
+4. Run focused validation, then `go test ./...` if appropriate
+5. Report risks, especially around concurrency and I/O
+
+## Refactor
+1. Preserve public behavior
+2. Avoid package-wide churn unless clearly justified
+3. Keep imports, naming, and package boundaries tidy
+4. Re-run tests after each meaningful step if the refactor is risky