Write user guide and packaging workflow updates - #47
Conversation
![terragon-labs[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
… reference - Add new docs/users-guide.md as primary guide for installation, usage tutorial, and full lading.toml reference. - Ensure documentation completeness with tests verifying all configuration keys are covered. - Update README.md to link prominently to the new user guide. - Update docs and tests to integrate the user guide into e2e scenarios. - Standardize release builds via Makefile using repository-managed virtual environment. This enhances onboarding and user experience by providing detailed, up-to-date documentation aligned with current features. Co-authored-by: terragon-labs[bot] <terragon-labs[bot]@users.noreply.github.com>
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Summary by CodeRabbitRelease Notes
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughDocument set expanded with a new user guide and revised usage notes; Makefile build-release now runs within the repository-managed uv environment; configuration validation centralised into per-section TOML key constants; E2E and unit tests extended to exercise tutorial publish flows and verify guide coverage. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (2)
🧰 Additional context used📓 Path-based instructions (2)docs/**/*.md📄 CodeRabbit inference engine (AGENTS.md)
Files:
**/*.md📄 CodeRabbit inference engine (AGENTS.md)
Files:
⚙️ CodeRabbit configuration file
Files:
🪛 LanguageTooldocs/users-guide.md[style] ~49-~49: To form a complete sentence, be sure to include a subject. (MISSING_IT_THERE) [grammar] ~153-~153: This phrase is duplicated. You should probably use “array of” only once. (PHRASE_REPETITION) 🔍 Remote MCP DeepwikiSummary — additional facts relevant to reviewing this PR
Sources
⏰ Context from checks skipped due to timeout of 120000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
Comment |
Reviewer's GuideIntroduces a new end-user user guide and aligns project documentation around it, standardises release builds through uv-driven packaging, and extends unit/E2E tests to validate documentation coverage and publish workflows, including new cargo invocation expectations. Flow diagram for documentation and tests integrationflowchart TD
DocsUsersGuide[docs/users-guide.md]
DocsUsageGuide[docs/usage-guide.md]
Readme[README.md]
UnitTests[test_users_guide.py]
E2EFeature[tests/e2e/features/e2e.feature]
E2ESteps[tests/e2e/steps/test_e2e_steps.py]
DocsUsersGuide -->|installation, tutorial, config reference| EndUsers
Readme -->|links to| DocsUsersGuide
Readme -->|links to| DocsUsageGuide
DocsUsageGuide -->|points readers to| DocsUsersGuide
UnitTests -->|assert sections and config keys exist in| DocsUsersGuide
E2EFeature -->|scenario definitions use| TutorialWorkflow[Tutorial bump and publish workflow]
TutorialWorkflow -->|invokes| LadingCLI[lading CLI]
LadingCLI -->|calls| CargoCommands[cargo check/test/package/publish]
E2ESteps -->|stub and assert| CargoCommands
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix: tests/e2e/steps/test_e2e_steps.py Comment on file def _recording_handler(
label: str,
expected_prefix: tuple[str, ...] = (),
expected_prefixes: tuple[tuple[str, ...], ...] = (),❌ New issue: Complex Method |
This comment was marked as resolved.
This comment was marked as resolved.
Refactor e2e test setup for cargo command stubs by introducing helper functions to validate command args and create invocation handlers. This removes duplicated logic and centralizes validation and recording of cmd-mox invocations for cargo commands like check, test, package, and publish. Co-authored-by: terragon-labs[bot] <terragon-labs[bot]@users.noreply.github.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
- Improved documentation for configuration keys including bump, publish, preflight sections. - Corrected wording and formatting for clarity in the tutorial section. - Added references for CLI flags like --forbid-dirty, --live, and environment variables. - Ensured coverage matches current code schema to prevent documentation drift. Co-authored-by: terragon-labs[bot] <terragon-labs[bot]@users.noreply.github.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
@coderabbitai Have the following now been resolved? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 20056 @leynos: Yes, all the review comments have been resolved! Here's the status: Overall Comments ✅
Individual Comments ✅Comment 1 (publish flow assertions) — Resolved. Two new
Comment 2 (CLI flags and env vars tests) — Resolved. New test Comment 3 (pluralise "array of string") — Resolved. All configuration tables now use "array of strings" and "array of array of strings". Comments 4-7 (second-person pronouns) — Resolved. All instances removed:
All review feedback has been addressed. 🎉 |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (12)
Makefile(1 hunks)README.md(1 hunks)docs/lading-design.md(1 hunks)docs/roadmap.md(1 hunks)docs/usage-guide.md(1 hunks)docs/users-guide.md(1 hunks)lading/config.py(6 hunks)pyproject.toml(2 hunks)tests/e2e/features/e2e.feature(1 hunks)tests/e2e/helpers/e2e_steps_helpers.py(2 hunks)tests/e2e/steps/test_e2e_steps.py(4 hunks)tests/unit/test_users_guide.py(1 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
docs/**/*.md
📄 CodeRabbit inference engine (AGENTS.md)
docs/**/*.md: Use the markdown files within thedocs/directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update relevant files in thedocs/directory when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve to keep documentation accurate and current.
docs/**/*.md: Use British English based on the Oxford English Dictionary (en-GB-oxendict) with suffixes: -ize in words like 'realize' and 'organization', -lyse in words like 'analyse' and 'paralyse', -our in words like 'colour' and 'behaviour', -re in words like 'centre' and 'calibre', double 'l' in words like 'cancelled' and 'counsellor', maintain 'e' in words like 'likeable', -ogue in words like 'catalogue'
Use the Oxford comma in documentation: 'ships, planes, and hovercraft' where it aids comprehension
Treat company names as collective nouns in documentation, for example 'Lille Industries are expanding'
Write headings in sentence case
Use Markdown headings (#, ##, ###, and so on) in order without skipping levels
Follow markdownlint recommendations for Markdown formatting
Always provide a language identifier for fenced code blocks; use 'plaintext' for non-code text
Use '-' as the first level bullet and renumber lists when items change in Markdown
Prefer inline links using text or angle brackets around the URL in Markdown
Ensure blank lines before and after bulleted lists and fenced blocks in Markdown
Ensure tables have a delimiter line below the header row in Markdown
Expand any uncommon acronym on first use, for example, Continuous Integration (CI)
Wrap paragraphs at 80 columns in documentation
Wrap code at 120 columns in documentation
Do not wrap tables in documentation
Use footnotes referenced with [^label] in Markdown documentation
Include Mermaid diagrams in documentation where they add clarity
When embedding figures in documentation, use 
**/*.md: For Markdown files (.md only), ensure changes pass lint checks viamake markdownlint.
For Markdown files (.md only), ensure Mermaid diagrams pass validation using nixie viamake nixie.
Files:
docs/lading-design.mdREADME.mddocs/roadmap.mddocs/usage-guide.mddocs/users-guide.md
⚙️ CodeRabbit configuration file
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -yse / -our) spelling and grammar
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/lading-design.mdREADME.mddocs/roadmap.mddocs/usage-guide.mddocs/users-guide.md
pyproject.toml
📄 CodeRabbit inference engine (.rules/python-00.md)
Configure tools like Ruff, Pyright, and Pytest using pyproject.toml
pyproject.toml: Use PEP 621[project]table for metadata (name, version, description, readme, requires-python, license, authors, keywords, classifiers) and runtime dependencies
Include mandatory PEP 621 fields:nameandversionin the[project]table
Include recommended[project]metadata fields:description,readme(pointing to README.md),requires-python(e.g., >=3.10),license,authors,keywords, andclassifiers
Declare runtime dependencies as a list in PEP 508 format within the[project]tabledependenciesfield (e.g., "requests>=2.25")
Use[project.optional-dependencies]to group development and documentation dependencies separately from production dependencies
Define console entry points in[project.scripts]table and GUI entry points in[project.gui-scripts]table to expose CLIs or GUIs
Declare[build-system]table withrequires = ["setuptools>=61.0", "wheel"]andbuild-backend = "setuptools.build_meta"to support editable installs
Set[tool.uv]withpackage = trueto ensureuv syncbuilds and installs your project into its virtual environment
Keeppyproject.tomlhuman-readable by editing it by hand when possible and using TOML-aware editors
Declaredynamic = ["version"]sparingly; only use it when your version is computed at build time (e.g., via setuptools_scm), and ensure your build backend supports dynamic metadata
Keep build system constraints minimal; omit[build-system]if you don't need editable installs, but settool.uv.package = trueto override default behavior
Files:
pyproject.toml
**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
**/*.py: For Python files, ensure changes pass all relevant unit and behavioral tests according to testing guidelines.
For Python files, ensure changes pass lint checks viamake lint.
For Python files, ensure changes adhere to formatting standards viamake check-fmt.
For Python files, ensure changes pass type checking viamake typecheck.
For Python development, refer to detailed guidelines in the.rules/directory including Python Code Style Guidelines, Context Managers, Exception Design/Raising/Handling/Logging, Generators, Project Configuration, Return Patterns, and Typing best practices.
**/*.py: Use snake_case.py for Python file names, naming them for their contents
Use PascalCase for class names
Use snake_case for variable and function names
Use UPPER_SNAKE_CASE for module-level constants
Prefix private or internal helpers with a single underscore (_)
Enable and maintain full static type coverage using Pyright; use typing everywhere
Use TypedDict or @DataClass(slots=True) for structured data
Avoid Any; use precise types (TypeVar, Protocol, Literal, Union) and typing.cast only when necessary with justification
Be explicit with return type annotations using -> None, -> str, etc., for all public functions and class methods
Prefer immutability: use tuples over lists and types.MappingProxyType for read-only mappings
Enforce strict mode in Pyright; treat all Pyright warnings as CI errors and use # pyright: ignore sparingly with explanation
Avoid side effects at import time; modules should not modify global state or perform actions on import
Document public functions, classes, and modules using NumPy-format docstrings
Use inline comments to explain tricky code and non-obvious logic
**/*.py: Use context managers (viacontextlib.contextmanageror__enter__/__exit__methods) to encapsulate setup and teardown logic for resource management (files, locks, connections, etc.)
Use@contextlib.contextmanagerdecorator for straightforward procedural setup...
Files:
tests/e2e/helpers/e2e_steps_helpers.pytests/e2e/steps/test_e2e_steps.pytests/unit/test_users_guide.pylading/config.py
⚙️ CodeRabbit configuration file
**/*.py: - Keep C90 / mccabe complexity ≤ 9
- Follow single responsibility and CQRS (command/query segregation)
- Prefer structural pattern matching to
- Prefer structural pattern matching over
isinstance()or imperative decomposition.- Docstrings must follow the
numpystyle guide. Use a single-line summary for private functions and methods, and full structured docs for all public interfaces.- Move conditionals with >2 branches to predicate/helper functions
- Avoid
eval,exec,pickle, monkey-patching,ctypes, unsafe shell- Every module must begin with a triple-quoted docstring explaining its purpose, utility, and usage, including example calls if appropriate.
- Comments and docs must follow en-GB-oxendict (-ize / -yse / -our) spelling and grammar
- Lint suppressions:
- Blanket
# noqa, file-level skips, and categories are forbidden- Only narrow in-line disables (
# noqa: XYZ) are permitted, and must be accompanied byFIXME:or a ticket link, and used only as a last resort.- Use
pytestfixtures for shared setup (conftest.pyorfixtures/)- Replace duplicate tests with
@pytest.mark.parametrize- Prefer
pytest-mockorunittest.mockfor stubs/mocks- Use
assert …, "message"over bare asserts- Reflect all API/behaviour changes in
docs/and update roadmap on completion- Files must not exceed 400 logical lines:
- Decompose large modules into subpackages
- Split large
match/caseor dispatch tables by domain and collocate with targets if appropriate- Move bulky data (fixtures, templates) to external files for parsing at runtime
- Mutable defaults and shadowed built-ins are forbidden
- All code must have clear type hints using modern style (
A | B,list[str],class Foo[A]:,type Bar = int, etc.), with ABC imports drawn from the correct stdlib module.- All path manipulation must be performed using pathlib for cross platform safety. Do not use string manipulation for extraction of path components or filename ele...
Files:
tests/e2e/helpers/e2e_steps_helpers.pytests/e2e/steps/test_e2e_steps.pytests/unit/test_users_guide.pylading/config.py
**/test_*.py
📄 CodeRabbit inference engine (.rules/python-00.md)
**/test_*.py: Use pytest idioms: prefer fixtures over setup/teardown, parametrize broadly, avoid unnecessary mocks
Group related tests using class with method names prefixed by test_
Write tests from a user's perspective; test public behavior, not internals
Avoid mocking too much; prefer test doubles only for external services or non-deterministic behaviors
Files:
tests/e2e/steps/test_e2e_steps.pytests/unit/test_users_guide.py
**/*test*.py
📄 CodeRabbit inference engine (.rules/python-exception-design-raising-handling-and-logging.md)
In tests, use narrow exception assertions with
pytest.raises()specifying the expected type and optionally constraining the message via regex (B017)
Files:
tests/e2e/steps/test_e2e_steps.pytests/unit/test_users_guide.py
🪛 LanguageTool
docs/lading-design.md
[style] ~619-~619: Would you like to use the Oxford spelling “Standardized”? The spelling ‘Standardised’ is also correct.
Context: ...out of sync with the documentation. - Standardised release builds via make build-release...
(OXFORD_SPELLING_Z_NOT_S)
docs/users-guide.md
[style] ~49-~49: To form a complete sentence, be sure to include a subject.
Context: ...atches = "per-crate" ``` lading.toml can be omitted entirely. When absent, `ladi...
(MISSING_IT_THERE)
[grammar] ~153-~153: This phrase is duplicated. You should probably use “array of” only once.
Context: ...invocation. | |aux_build | array of array of strings |[]` | Extra commands (tok...
(PHRASE_REPETITION)
[style] ~153-~153: Would you like to use the Oxford spelling “tokenized”? The spelling ‘tokenised’ is also correct.
Context: ... of strings | [] | Extra commands (tokenised) to run before cargo pre-flight checks....
(OXFORD_SPELLING_Z_NOT_S)
🔍 Remote MCP
The search results show similar Rust workspace publishing tools but not the specific lading project. Let me search more directly for lading and also check for information about the uv tool that's being integrated into the build process.Based on my research, I have gathered sufficient context about the tools and technologies referenced in this PR. Let me now compile the findings.
Summary of Relevant Context for PR Review
Build & Packaging Context
uv is a fast Python package manager and project manager that provides drop-in replacements for common pip, pip-tools, and virtualenv commands, extending their interfaces with advanced features such as dependency version overrides, platform-independent resolutions, and reproducible resolutions. The Makefile changes that integrate uv run python -m build align with uv's ability to build source distributions and binary distributions (wheels) for projects. This addresses the PR objective of standardizing release builds via the repository-managed virtual environment.
The pyproject.toml change to add "build" to dev-dependencies is appropriate since uv build is used to build source distributions and binary distributions (wheel) for projects, placing built artifacts in a dist/ subdirectory by default.
Configuration Schema & Testing
The PR introduces public constants in lading/config.py that centralize TOML key validation. The new test file tests/unit/test_users_guide.py appropriately validates documentation completeness by:
- Testing that the user guide documents all supported config keys derived from the new constants
- Verifying CLI flags and environment variable references appear in documentation
This approach ensures the user guide stays synchronized with the actual configuration schema as it evolves.
Test Refactoring Assessment
The E2E test refactoring addresses complexity concerns by extracting three helper functions (_validate_args_prefix, _validate_target_dir, _create_recording_handler) and converting to data-driven stub configuration. This reduces cyclomatic complexity in given_cargo_commands_stubbed and improves maintainability of the cargo command mocking logic.
Documentation Coverage
The user guide addition is comprehensive, covering installation methods, a tutorial workflow, and full configuration reference—all appropriate for an end-user document. The test-driven validation ensures documentation stays current with actual supported options as the tool evolves.
[::web_search::] for uv and Python build tools, [::web_search::] for Rust versioning and publishing context
⏰ Context from checks skipped due to timeout of 120000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Sourcery review
🔇 Additional comments (29)
docs/roadmap.md (1)
252-252: Roadmap task completion aligns with deliverables.The transition to completed status for "Write User Guide" and "Package for PyPI" correctly reflects the addition of
docs/users-guide.mdand the standardised build workflow viauv.Also applies to: 260-260
Makefile (1)
21-22: Build dependency and uv integration improve reproducibility.The new dependency on the
buildtarget ensures the virtual environment is prepared before creating release artefacts. Wrapping the build command withuv runstandardises the execution context and aligns with the addition ofbuildtopyproject.tomldev dependencies.pyproject.toml (2)
4-4: Description update provides clearer project purpose.The updated description accurately conveys the tool's functionality for end users and aligns with the comprehensive user guide being added.
31-31: Build dependency addition supports release workflow.Adding
buildto the dev dependency group enables themake build-releasetarget to produce distribution artefacts viauv run python -m build, as documented in the external tools context.README.md (1)
35-40: Learn more section provides clear navigation.The restructured section effectively directs users to the appropriate guide based on their needs (end-user vs implementation details).
docs/usage-guide.md (1)
7-16: Installation guidance and cross-reference enhance usability.The pointer to the end-user tutorial provides clear navigation, and the expanded installation notes accurately describe both wheel-based installation and development workflows.
docs/lading-design.md (1)
612-620: Phase 4 documentation accurately reflects deliverables.The summary correctly describes the user guide addition, test coverage for configuration synchronisation, and standardised build workflow.
tests/e2e/features/e2e.feature (2)
21-21: Flag assertion step enhances test coverage.The new step validates that
--allow-dirtyis correctly omitted when--forbid-dirtyis set, ensuring the dirty-tree guard behaves as expected.
24-36: Tutorial workflow scenario provides comprehensive validation.The new scenario exercises the complete bump-and-publish sequence documented in the user guide, verifying version propagation, dependency updates, and publish-flow assertions including
--allow-dirtypresence in the default path.docs/users-guide.md (5)
1-11: Introduction provides clear tool overview.The opening effectively describes the tool's capabilities without using second-person pronouns, adhering to documentation guidelines.
12-30: Installation instructions cover both workflows.The section appropriately documents wheel-based installation for distribution and
uv-based development setup, with properly annotated code blocks.
32-95: Tutorial workflow matches test scenarios.The step-by-step tutorial aligns with the E2E test scenario added in
tests/e2e/features/e2e.feature, ensuring documentation and test coverage remain synchronised.
97-152: Configuration reference provides comprehensive coverage.The complete example and per-section tables document all supported
lading.tomlkeys, facilitating the test-driven validation implemented intests/unit/test_users_guide.py.
158-176: CLI reference documents key flags and environment variables.The section covers
--workspace-rootpositioning flexibility andLADING_LOG_LEVELconfiguration, addressing common operational concerns.tests/e2e/helpers/e2e_steps_helpers.py (3)
39-47: LGTM: Enhanced signature supports multiple prefix validation.The updated signature and error message construction correctly support validation against multiple possible prefixes, aligning with the data-driven stubbing approach introduced in test_e2e_steps.py.
50-54: LGTM: Error message accurately reflects positional-independent validation.The updated message correctly indicates that
--target-dir=...is expected anywhere in the args list, matching the flexible validation logic in_validate_target_dir.
99-107: LGTM: Consistent with config-driven stub refactoring.The shift from
cmd_mox.mocktocmd_mox.stubaligns with the broader refactoring of cargo command stubbing in test_e2e_steps.py, ensuring uniform stubbing mechanisms across the E2E test suite.tests/unit/test_users_guide.py (4)
1-8: LGTM: Clean module structure.The module docstring clearly states intent, and imports are minimal and appropriate for documentation coverage testing.
10-17: LGTM: Clear section presence validation.The test effectively guards against removal of Phase 4.2 required sections using straightforward substring checks.
20-38: LGTM: Robust documentation drift guard using source of truth.The test derives expected configuration keys from
lading/config.pyconstants, correctly handles the nested[bump.documentation]section, and provides clear failure messages. This ensures the user guide stays synchronised with the actual configuration schema.
41-61: LGTM: Comprehensive CLI and environment variable coverage.The test guards against drift in CLI flag and environment variable documentation, verifying presence of key invocation examples and configuration references. Separate assertions for CLI and environment terms provide clear diagnostic output.
lading/config.py (2)
22-39: LGTM: Well-structured centralized key validation.The constants follow best practices (UPPER_SNAKE_CASE,
typ.Final,frozenset) and accurately capture the valid keys for each configuration section. The centralisation enables reuse in tests and ensures consistent validation across the configuration loading logic.
67-69: LGTM: Consistent validation using centralized constants.All
from_mappingmethods correctly use the centralized key constants with_validate_mapping_keys, maintaining existing validation behaviour whilst enabling reuse in tests. The context strings provide clear error messages.Also applies to: 87-87, 109-109, 143-143, 188-188
tests/e2e/steps/test_e2e_steps.py (6)
29-38: LGTM: Clean prefix validation with flexible length matching.The helper correctly validates that invocation arguments begin with one of the allowed prefixes, handling variable-length prefixes and empty prefix sets (which allow any args).
41-44: LGTM: Position-independent target directory validation.The helper correctly scans all arguments for
--target-dir=, avoiding brittle positional checks.
47-64: LGTM: Well-structured handler factory reduces duplication.The factory pattern effectively encapsulates validation and recording logic, enabling data-driven stub configuration. The closure correctly captures label, records, and validation requirements.
89-123: LGTM: Data-driven stubbing reduces complexity effectively.The refactored approach replaces bespoke handlers with configuration-driven logic, reducing cyclomatic complexity and improving maintainability. The stub configuration correctly models expected argument prefixes and target-dir requirements for each cargo command.
152-159: LGTM: Separate step enables default publish flow testing.The new when step correctly captures the default publish behaviour (with allow-dirty), enabling distinct test scenarios for different publish flag combinations as requested in prior review feedback.
260-277: LGTM: Explicit assertions guard against publish flag regressions.The new then steps correctly verify that
cargo publishis invoked with the appropriate flags for default (--allow-dirty --dry-run) versus forbid-dirty (--dry-run only) flows, directly addressing prior review feedback.
Corrected 'Standardised' to 'Standardized' in lading-design.md and 'tokenised' to 'tokenized' in users-guide.md to improve documentation accuracy. Co-authored-by: terragon-labs[bot] <terragon-labs[bot]@users.noreply.github.com>
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
1 participant
Summary
Changes
Documentation
Build & Packaging
Tests
Documentation & Roadmap
Test Plan
Notes for reviewers
🌿 Generated by Terry
ℹ️ Tag @terragon-labs to ask questions and address PR feedback
📎 Task: https://www.terragonlabs.com/task/d20422f4-3778-4c63-bb16-b2715e46c937
Summary by Sourcery
Add an end-user user guide, align documentation and roadmap with the new guide and packaging workflow, standardise release builds using uv, and extend tests to cover documentation and publish workflows.
New Features:
Enhancements:
Build:
Tests: