-
LLMs were explicitly employed (write access) for some portions of the project:
- Documentation
- diagramming DSLs (mermaid/plantuml)
- minor documentation commentary over code when necessary
- commit messages (conventional commits style) : tag lines and descriptions
- CI/CD setup
- Documentation
-
Apart from the above, they were granted read-only access to the repository to help me discuss the domain-oriented aspects (SWE Wisdom, writing effective Java, Design, Architecture) I wish to improve my grasp of: the source code (other than deterministically auto-generated (
gradle initfor instance) files) is hand-crafted and have marked any exceptions (if any) in [LLM generated] fences.
- commentary upon dailies
- onboarding project towards picking up the tech stack
- documenting an index into the items from the book for quick reference during implementation of project NIL
| Branch | Purpose | CI | CD | Guidelines |
|---|---|---|---|---|
main |
Production branch | ✅ Yes | ✅ Yes | Merged from dev only. Full CI/CD pipeline runs. |
dev |
Development/integration branch | ✅ Yes | ❌ No | Main development branch. CI runs on all commits. |
journal |
Personal documentation & logs | ❌ No | ❌ No | Branch for onboarding logs and commentary. All commits MUST include [skip ci] in the message. |
- All commits to the
journalbranch must include[skip ci]in their commit message to prevent unnecessary CI triggers - Example:
git commit -m "Update journal entry [skip ci]"
- When merging from
journaltomain, ensure the merge commit includes[skip ci]to bypass CI checks - Example:
git merge journal --no-ff -m "Merge journal branch [skip ci]"
- For feature development: Create feature branches off
dev, then merge intodevvia PR - For onboarding logs: Commit directly to
journalwith[skip ci]tag - For production: Merge
devintomainwhen ready for deployment