[EPIC-1-3] Add development tooling and quality gate configurations

[deserat]

Summary

This PR adds standardized configuration files for development tooling and quality gates across all services (Python and Rust), along with consolidated development documentation.

Related Issue

Closes #8 (EPIC-1-3: Development Tooling and Quality Gates)

Changes

Python Configuration (api-service)

• pytest.ini: Test runner configuration with test discovery patterns and markers (unit, integration, slow)
• pyproject.toml: Modern single-source-of-truth configuration combining:
  • pytest configuration (test paths, markers, addopts)
  • ruff configuration (line-length 100, enabled rule sets: E, W, F, I, N, UP, B, C4)
  • pyright configuration (basic type checking mode, Python 3.11 target)

Rust Configuration (cli + sync-service)

• rustfmt.toml: Formatting configuration for both services with:
  • Max width: 100 characters (matches Python)
  • Edition: 2021
  • Import/module reordering enabled
  • Comment formatting enabled

Documentation

• docs/development.md: Comprehensive development workflow guide consolidating:
  • Quick start commands for running tests and linters
  • Testing strategy for Python (90% coverage target) and Rust (80% target)
  • Code quality tools documentation (ruff, pyright, cargo fmt, cargo clippy)
  • Git-flow workflow with branch naming conventions
  • Commit message format (conventional commits)
  • Code review checklist
  • Troubleshooting guide
  • Resource links

Testing

• Verified pytest configuration loads correctly (markers available)
• Verified ruff uses pyproject.toml (line-length 100, UP rules enabled)
• Verified pyright is installed and accessible (v1.1.408)
• Verified rustfmt.toml files exist with correct content
• No changes to existing code - only configuration files added

Configuration Verification

Python (api-service):

cd api-service

# Pytest configuration loaded
uv run pytest --markers
# Shows: unit, integration, slow markers

# Ruff configuration working
uv run ruff check app/ --show-files
# Uses line-length 100 from pyproject.toml

# Pyright configuration working
uv run pyright --version
# pyright 1.1.408

Rust (cli + sync-service):

# Configuration files exist
ls -la cli/rustfmt.toml
ls -la sync-service/rustfmt.toml

# Both configured with max_width=100, edition=2021

Design Decisions

1. pyproject.toml over separate files: Used modern PEP 518 standard for single-source-of-truth Python configuration instead of separate pytest.ini, ruff.toml files
2. Consistent line length: Set max_width/line-length to 100 for both Python and Rust (more readable than 80, not too wide)
3. Deferred pre-commit hooks: Marked as optional in Issue Development Tooling and Quality Gates #8, can be added later once base configs are proven
4. Consolidated documentation: Created docs/development.md to extract and organize developer-focused content from standards.md and setup.md

Acceptance Criteria from Issue #8

• Python tooling: pytest.ini and pyproject.toml created with tool configs
• Rust tooling: rustfmt.toml created for both cli and sync-service
• Documentation: Development workflow guide created (docs/development.md)
• Sample tests verify: Existing tests remain unchanged, will work with new configs
• Commands documented: All test/lint commands in development.md
• Configuration best practices: Modern pyproject.toml, consistent formatting rules

Files Added

• api-service/pytest.ini (191 bytes)
• api-service/pyproject.toml (1,054 bytes)
• cli/rustfmt.toml (325 bytes)
• sync-service/rustfmt.toml (334 bytes)
• docs/development.md (18,293 bytes)

Total: 5 files, 629 lines added

Checklist

• Configuration files follow project conventions
• Documentation is clear and comprehensive
• No secrets or sensitive data committed
• All configuration files use correct file formats
• No changes to existing code (configuration only)
• Branch name follows convention (feature/EPIC-1-3-development-tooling)

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @deserat, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request establishes a robust and standardized development environment across the project's Python and Rust services. It introduces unified configuration files for testing, linting, and type checking, ensuring consistent code quality and developer experience. Furthermore, it centralizes all development-related documentation into a single, comprehensive guide, streamlining onboarding and promoting best practices for all contributors.

Highlights

• Standardized Python Tooling: Introduced pyproject.toml for the api-service to consolidate configurations for pytest (test runner), Ruff (linter/formatter), and Pyright (type checker), ensuring consistent Python development practices.
• Consistent Rust Formatting: Added rustfmt.toml files to both cli and sync-service to enforce standardized code formatting, including a maximum line width of 100 characters and reordering of imports/modules.
• Comprehensive Development Documentation: Created docs/development.md, a central guide covering quick start commands, detailed testing strategies (Python 90% coverage, Rust 80% coverage), code quality tools, Git workflow, commit message conventions, and a code review checklist.
• Unified Configuration Approach: Adopted pyproject.toml as the single source of truth for Python project configuration, aligning with modern PEP standards and simplifying tool management.
• Quality Gate Definitions: The new documentation and configurations establish clear quality gates for both Python and Rust, including passing linters, type checks, and meeting test coverage thresholds.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a great step forward for the project's quality and developer experience by introducing standardized tooling and comprehensive documentation. The choice of tools like Ruff, Pyright, and pyproject.toml for configuration is excellent. The new development.md guide is thorough and will be very helpful for developers. My review focuses on a small point of redundancy in the Python test configuration to fully align with the stated goal of a single source of truth, and updating the documentation to reflect this.

[deserat]

@gemini-code-assist Thank you for the excellent catch! You're absolutely right that having both pytest.ini and pytest configuration in pyproject.toml contradicts our goal of using pyproject.toml as the single source of truth.

I've addressed both comments:

1. ✅ Removed api-service/pytest.ini - All pytest configuration now lives exclusively in pyproject.toml under [tool.pytest.ini_options]
2. ✅ Updated docs/development.md line 253 - Changed from "Configuration in both pytest.ini and pyproject.toml" to "Configuration in pyproject.toml"

Changes Summary

Removed:

• api-service/pytest.ini (redundant duplicate of pyproject.toml configuration)

Modified:

• docs/development.md (line 253: updated to reflect single source of truth)

Unchanged:

• api-service/pyproject.toml (already contains complete pytest configuration)

Verification

Verified pytest works correctly with the single-source configuration:

• ✅ pytest v7.4.4 loads successfully
• ✅ All pytest configuration in [tool.pytest.ini_options] section:
  • testpaths = ["tests"]
  • python_files/classes/functions patterns configured
  • addopts = "-v --tb=short --strict-markers"
  • markers: unit, integration, slow

This change eliminates configuration redundancy and fully aligns with the modern Python packaging standard (PEP 518). All pytest functionality (test discovery, markers, addopts) is preserved in the pyproject.toml configuration.

Updated commit: 1024e37