|
3 | 3 | ## Description |
4 | 4 | A simple Java client for ACINQ's [phoenixd REST API](https://phoenix.acinq.co/server/api). It wraps the HTTP endpoints and exposes typed requests and responses. |
5 | 5 |
|
| 6 | +## Project |
| 7 | +- Maintain the versions in the configuration section of the parent pom.xml file. |
| 8 | + |
| 9 | +## Coding |
| 10 | +- When writing code, follow the "Clean Code" principles: |
| 11 | + - [Clean Code](https://dev.398ja.xyz/books/Clean_Architecture.pdf) |
| 12 | + - Relevant chapters: 2, 3, 4, 7, 10, 17 |
| 13 | + - [Clean Architecture](https://dev.398ja.xyz/books/Clean_Code.pdf) |
| 14 | + - Relevant chapters: All chapters in part III and IV, 7-14. |
| 15 | + - [Design Patterns](https://github.com/iluwatar/java-design-patterns) |
| 16 | + - Follow design patterns as described in the book, whenever possible. |
| 17 | +- When commiting code, follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. |
| 18 | +- When adding new features, ensure they are compliant with the Cashu specification (NUTs) provided above. |
| 19 | + |
| 20 | +## Documentation |
| 21 | + |
| 22 | +- When generating documentation: |
| 23 | + - Follow the Diátaxis framework and classify each document as a tutorial, how-to guide, reference, or explanation. |
| 24 | + - Place new Markdown files under `docs/<section>` matching the chosen category. |
| 25 | + - Start each document with a top-level `#` heading and a short introduction that states the purpose. |
| 26 | + - Link the document from `docs/README.md` in the corresponding section. |
| 27 | + - Use relative links to reference other documents and keep code snippets minimal and tested. |
| 28 | + - Consult the following resources on Diátaxis for guidance: |
| 29 | + - https://github.blog/developer-skills/documentation-done-right-a-developers-guide/ |
| 30 | + - https://diataxis.fr/ |
| 31 | + - https://diataxis.fr/start-here/ |
| 32 | + - https://diataxis.fr/how-to-use-diataxis/ |
| 33 | + - https://diataxis.fr/tutorials/ |
| 34 | + - https://diataxis.fr/how-to-guides/ |
| 35 | + - https://diataxis.fr/tutorials-how-to/ |
| 36 | + - https://diataxis.fr/quality/ |
| 37 | + - https://diataxis.fr/complex-hierarchies/ |
| 38 | + - https://diataxis.fr/compass/ |
6 | 39 |
|
7 | 40 | ## Testing |
8 | 41 |
|
9 | 42 | - Always run `mvn -q verify` from the repository root before committing your changes. |
10 | 43 | - Include the command's output in the PR description. |
11 | 44 | - If tests fail due to dependency or network issues, mention this in the PR. |
12 | | -- Update the `README.md` file if you add or modify features. |
| 45 | +- Update the documentation files if you add or modify features. |
13 | 46 | - Update the `pom.xml` file for new modules or dependencies, ensuring compatibility with Java 21. |
14 | 47 | - Verify new Dockerfiles or `docker-compose.yml` files by running `docker-compose build`. |
15 | 48 | - Document new REST endpoints in the API documentation and ensure they are tested. |
16 | | -- Add unit tests for new functionality, covering edge cases. |
| 49 | +- Add unit tests for new functionality, covering edge cases. Follow "Clean Code" principles on unit tests, as described in the "Clean Code" book (Chapter 9). |
17 | 50 | - Ensure modifications to existing code do not break functionality and pass all tests. |
18 | 51 | - Add integration tests for new features to verify end-to-end functionality. |
19 | 52 | - Ensure new dependencies or configurations do not introduce security vulnerabilities. |
20 | | -- Maintain the versions in the configuration section of the pom.xml files. |
21 | 53 | - Add a comment on top of every test method to describe the test in plain English. |
22 | 54 |
|
23 | 55 | ## Pull Requests |
24 | 56 |
|
| 57 | +- Always follow the repository's PR submission guidelines and use the PR template located at `.github/pull_request_template.md`. |
25 | 58 | - Summarize the changes made and describe how they were tested. |
26 | 59 | - Include any limitations or known issues in the description. |
27 | | -- Add a "Network Access" section summarizing blocked domains if network requests were denied. |
28 | | -- Ensure all new features, modules, or dependencies are properly documented in the `README.md` file. |
29 | | -- Always follow the repository's PR submission guidelines and use the PR template located at `.github/pull_request_template.md`. |
30 | | -- When implementing features, consult the API specifications: |
31 | | - |
32 | | -## PR Quality Gate |
33 | | - |
34 | | -- Always follow the PR submission guidelines and use the [PR template](.github/pull_request_template.md) when creating pull requests. |
35 | | -- PR summaries must reference modified files with file path citations (e.g. `F:path/to/file.java†L1-L2`). |
36 | | -- PR titles and commit messages must follow the `type: description` naming format. |
37 | | -- Allowed types: feat, fix, docs, refactor, test, chore, ci, build, perf, style. |
38 | | -- The description should be a concise verb + object phrase (e.g., `refactor: Refactor auth middleware to async`). |
39 | | -- Include a Testing section listing the commands run. Prefix each command with ✅, ⚠️, or ❌ and cite relevant terminal output. |
40 | | -- If network requests fail, add a Network Access section noting blocked domains. |
41 | | -- When TODOs or placeholders remain, include a Notes section. |
42 | | -- Review AI-generated changes with developer expertise, ensuring you understand why the code works and that it remains resilient, scalable, and secure. |
43 | | -- Use `rg` for search instead of `ls -R` or `grep -R`. |
44 | | -- Ensure all new features are compliant with the API specification provided above. |
| 60 | +- Ensure all new features are compliant with the Cashu specification (NUTs) provided above. |
0 commit comments