docs: add local development guide

[malon64]

Automated changes by agent.\n\nInstruction:\n# DEV TASK PROMPT (FLOE)

Project context

Repo: malon64/floe
Language: Rust (main), plus orchestrator packages in Python.

Floe is a config-driven data ingestion and technical validation tool.
It is primarily used by data engineers / analytics engineers who need to:

• ingest files (CSV/JSON/Parquet/Excel and cloud-backed sources),
• enforce schema and data-quality checks,
• route accepted/rejected data outputs,
• produce deterministic run reports for operations and monitoring,
• integrate execution with orchestrators (e.g., Airflow/Dagster).

Core product goals:

• predictable, reproducible ingestion runs,
• explicit validation behavior driven by YAML config,
• clear observability (logs + reports),
• production-grade CLI ergonomics for local and CI usage.

When implementing tasks, preserve backwards compatibility of existing config semantics unless the task explicitly requests a breaking change.
Goal: produce clean, idiomatic, performant code consistent with existing architecture.

Task

Objective

Polish docs navigation around local development by adding a concise related-docs/navigation block and ensuring links are correct.

Scope (where to change)

• docs/local-dev.md
• optionally one docs navigation location if needed (keep minimal)

Non-goals (what NOT to touch)

• No code changes.
• No broad rewrite across many docs.
• No CI/workflow edits.

Implementation notes / constraints

• Add a short “Related docs” section with relevant links (e.g., installation, cli, checks).
• Keep it concise and useful.
• Validate link targets exist and render in GitHub markdown.

Speed policy:

• Keep discovery lean and proportional to task size.
• For docs-only tasks (docs/**, README.md), do not run heavy runtime validation (cargo build, cargo run, cargo clippy, cargo test) unless explicitly requested in the task.
• For docs-only tasks, prefer: quick path existence checks + markdown consistency checks + focused edit + commit.

Tests (mandatory)

What to add/update

• Unit tests: put them under crates/floe-core/tests/unit/** (or the relevant crate’s tests dir).

• Integration tests (only if needed for the change): crates/floe-core/tests/integration/**.

• Docs-only task: no Rust/Python tests to add.

• Verify all introduced links resolve.

Local self-validation (must run before finishing)

Run and fix until green, but scope checks to impacted areas only:

• Always run formatting/lint for touched language(s):
  • Rust touched: cargo fmt and cargo clippy --workspace --all-targets -- -D warnings
  • Python orchestrator touched: relevant formatter/linter only for touched paths
• Rust tests policy (mirror CI selective strategy in .github/workflows/ci.yml):
  • Code changes in Rust modules: run only the relevant filtered test targets (for example cargo test -p floe-core --test unit <module_path>:: or cargo test -p floe-core --test integration when applicable).
  • Reuse compiled artifacts across commands in the same run (avoid clean rebuild loops; do not run cargo clean unless strictly needed).
  • Docs-only changes (e.g., README.md, docs/**): do not run Rust tests.
  • Avoid full workspace/crate test runs unless explicitly required by the task.
• Python tests policy:
  • Run only relevant pytest path(s) when Python code is touched.
  • Docs-only changes: no pytest required.

Git / PR requirements (mandatory)

• Start from main (worktree branch created from origin/main).
• Make focused commits.
• Ensure changes are staged: git add -A
• Commit with a clear message.
• Push branch to origin.
• Ensure a PR can be created (there must be at least one commit).

Acceptance criteria

• Docs navigation is improved with minimal changes.
• Related links are valid and useful.
• PR title should be simple and evocative.

Output requirement

When done, provide:

• Summary of changes
• Commands run + results
• What tests were added/updated and where