- Mount best-practices context at /workspace/best-practices/ (was /opt/harness/context/best-practices/) for consistent agent access - Fix /workspace/working/ → /workspace/project/ in all CLAUDE.md files (planning, spec-writing, security-review, code-methodology, qwen-code-methodology, test-writing) - Update best-practices path references in all CLAUDE.md files to /workspace/best-practices/ Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4.2 KiB
Code Methodology Context
Best Practices Review
Before starting any task:
- Check if
/workspace/best-practices/INDEX.mdexists - If it exists, read it to see available topics
- Identify relevant topics for the current task:
- Python task → read
test-driven-development.md,spec-driven-development.md - Kubernetes task → read
kubernetes.md - Shell scripts → read
scripting.md
- Python task → read
- Read the relevant topic files from
/workspace/best-practices/ - Apply those practices to your work
If /workspace/best-practices/ doesn't exist, proceed without — it's not mandatory.
Spec-Driven Development Workflow
- Read the spec — Read relevant files in
spec/before writing any code - Write tests first — Create test cases from spec requirements before implementing (see
/workspace/best-practices/test-driven-development.mdand/workspace/best-practices/spec-driven-development.mdif available) - Implement iteratively — Build implementation to satisfy tests and spec
- Write session log — Document what was accomplished, decisions made, and gotchas discovered
Conventions
- Python 3.12+ with type hints throughout
- Pydantic v2 for all data models and settings
- pytest for testing with clear, descriptive test names
- Structured JSON logging for all output
- Configuration via environment variables — no hardcoded config
- No shell scripts inside containers — use Python for error handling
Code Quality Rules
- Do not add features, refactor code, or make improvements beyond what was asked
- Validate inputs at system boundaries only, trust internal interfaces
Agent Safety Rules
These rules exist because container agents have repeatedly made these mistakes in production runs.
Python Module Safety
Never call sys.exit() at module level or inside except ImportError blocks. This causes import
failures in other modules that import this one. Use a flag pattern instead:
_HAS_OPENAI = True
try:
import openai
except ImportError:
_HAS_OPENAI = False
Check the flag at call time:
def use_openai():
if not _HAS_OPENAI:
raise RuntimeError("openai is not installed")
...
Pydantic Validators
- Use
@model_validator(mode='after')when validation needs cross-field access or must fire for default values @field_validatoronly fires when a field is explicitly provided — it will not run for fields that fall back to their default
File Editing Policy (CRITICAL)
NEVER use the Write tool on any file that already exists in /project.
This is the single most important rule. Container agents have repeatedly destroyed complex source files (1000+ lines) by writing new minimal stub versions. The effects are catastrophic and hard to detect because the task still "succeeds" (exit 0).
The correct workflow for modifying any existing file:
- Read the file first (Read tool)
- Edit with targeted changes (Edit tool) — ONLY the specific function, class, or field
- Never rewrite an entire file from scratch with Write
- Never "simplify" or "restructure" a file unless that is the explicit task
The Write tool is ONLY for creating brand-new files that do not yet exist.
Other file management rules:
- Never create backup copies of files or directories before modifying them
- Edit files in place — do not create paths ending in
_orig,_old,_bak, or_backup - Do not rename existing files or directories before modifying them
- In automated runs there is no one to clean up junk directories
Async Test Patterns
- Test functions for async code must be
async defdecorated with@pytest.mark.asyncio - A sync
def test_function that calls an async function receives a coroutine object, not the result — the test will silently pass without executing the async logic
Session Logging
Write a session log to /project/memory/log/<date>.<time>.md (e.g., 2026-03-24.041500.md) with:
- Summary: One paragraph of what was accomplished
- Decisions: Key choices made and reasoning
- Gotchas: Issues discovered with topic tags (e.g.,
[python],[docker]) - Open Questions: Unresolved items for follow-up
- Process Notes: What worked well, areas for improvement
Omit empty sections.