feature-development

name	feature-development
description	Use when implementing new features in rvlibs following conventions and existing patterns. Load during the Implementation phase of SDLC.

feature-development

SDLC Phase: Implementation

Implement features following rvlibs conventions and existing patterns.

Principles

• Follow existing patterns — Before writing code, read similar modules in the same crate for style reference. Mimic their structure, naming, and patterns.
• Design first, code second — Know your types and signatures before writing implementation bodies.
• Implement in layers — Start with types and data structures, then trait implementations, then public API functions, then tests.
• One concern per commit — Each meaningful change should be a separate, reviewable commit.

Pre-Implementation Checklist

• Read the relevant crate's docs/ files (architecture, conventions, testing)
• Read similar existing modules for style reference
• Read AGENTS.md for workspace-wide conventions
• Confirm the module placement (new crate? new submodule? existing module?)
• Sketch the public API surface before writing body code

Implementation Guidelines

Types and Data Structures

• Use newtypes for type safety over raw primitives where domain meaning exists.
• Derive Debug, Clone, PartialEq where semantically valid.
• Prefer pub fields over getters/setters for simple data structs.
• Use const generics for fixed-size collections (VecN<T, N>, MatN<T, R, C>).

Traits

• One capability per trait. If a trait has 5+ methods, consider splitting.
• Prefer static dispatch (generics) over dyn trait objects.
• Provide blanket impls where useful.
• Implement standard library traits (From, Into, Display, Default, etc.) where natural.

Functions and Methods

• Fallible operations return Result<T, String> or rvlibs::Result<T>.
• Panics are reserved for programming errors only.
• Builder methods consume self and return Self. Terminal methods return the final type.
• Document panics, errors, and safety preconditions in doc comments.

Documentation

• All public items must have doc comments (///).
• Module-level docs (//!) explain the module's purpose and key design decisions.
• Include a usage example in the module or type doc comment when the API is non-trivial.

Avoiding Common Pitfalls

• No vendor prefixes (RvlibsFoo) — disambiguate by module path.
• No unsafe unless absolutely necessary and documented with safety invariants.
• Keep external dependencies to a minimum. Question each new dependency.
• No hardcoded paths, URLs, or environment-specific values.

Verification

• cargo check passes
• cargo clippy passes with -D warnings
• cargo fmt --check passes
• cargo test passes
• New features have tests covering the happy path and edge cases

Output Requirements

• Complete implementation with all types, traits, and functions
• Tests for new public API
• Doc comments on all public items
• Updated docs/roadmap.md if the feature was planned there