Skip to content

docs: add DAILY-FLOW and PHASE-FLOW documentation#18

Closed
w7-mgfcode wants to merge 2 commits into
mainfrom
docs/flow-documentation
Closed

docs: add DAILY-FLOW and PHASE-FLOW documentation#18
w7-mgfcode wants to merge 2 commits into
mainfrom
docs/flow-documentation

Conversation

@w7-mgfcode
Copy link
Copy Markdown
Owner

@w7-mgfcode w7-mgfcode commented Jan 26, 2026

Documentation only

Summary by Sourcery

Document standardized development and phase completion workflows for the ForecastLabAI project.

Documentation:

  • Add DAILY-FLOW documentation describing the daily development cycle, branching model, CI requirements, release flow, and commit message conventions.
  • Add PHASE-FLOW documentation outlining the end-to-end phase lifecycle, including integration to main, release, documentation updates, phase snapshots, dev sync, and troubleshooting steps.

Summary by CodeRabbit

  • Documentation
    • Added daily development workflow guide covering branch strategy, development cycle, and commit conventions
    • Added phase completion flow documentation with lifecycle diagrams, checklists, and troubleshooting reference

✏️ Tip: You can customize this high-level summary in your review settings.

- DAILY-FLOW.md: Daily development workflow (branch strategy, PR flow, commands)
- PHASE-FLOW.md: Phase completion workflow (lifecycle, snapshot, sync)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@sourcery-ai
Copy link
Copy Markdown

sourcery-ai Bot commented Jan 26, 2026

Reviewer's Guide

Adds two new documentation guides describing the daily development workflow and the phase completion workflow (including branching, release, CI, and snapshot processes) for the ForecastLabAI project.

Sequence diagram for the phase snapshot workflow

sequenceDiagram
  actor Developer
  participant Git as Git_Repository
  participant GitHub as GitHub_Repo
  participant CI as CI_Workflows
  participant Snapshot as Phase_Snapshot_Workflow

  Developer->>Git: git checkout main
  Developer->>Git: git pull origin main
  Developer->>Git: git checkout -b phase-N
  Developer->>GitHub: git push origin phase-N

  GitHub->>CI: Trigger phase-snapshot.yml
  CI->>Snapshot: Start phase snapshot job

  Snapshot->>Snapshot: Run lint check
  Snapshot->>Snapshot: Run type checks
  Snapshot->>Snapshot: Run migration check
  Snapshot->>Snapshot: Run unit and integration tests

  Snapshot->>Snapshot: Generate metadata JSON
  Snapshot->>Snapshot: Collect validation results
  Snapshot->>Snapshot: Create markdown report
  Snapshot->>GitHub: Upload audit artifact
  Snapshot->>GitHub: Create annotated tag

  CI-->>Developer: Report workflow status
Loading

Flow diagram for the daily development workflow

flowchart TD
  A[Start day
  Update dev branch] --> B[Create feature branch
  feat/prp-X-feature-name]
  B --> C[Implement changes
  Regular commits]
  C --> D[Run local checks
  ruff, mypy, pyright, pytest]
  D --> E{Local checks
  all pass}
  E -- No --> C
  E -- Yes --> F[Push feature branch
  to origin]
  F --> G[Create PR
  base dev]
  G --> H[CI pipeline
  lint, type, tests,
  migration, review]
  H --> I{CI and review
  successful}
  I -- No --> G
  I -- Yes --> J[Merge PR
  into dev
  squash, delete branch]
  J --> K{Feature
  complete}
  K -- No --> B
  K -- Yes --> L[Create PR
  dev to main]
  L --> M[CI on main PR]
  M --> N{CI passes}
  N -- No --> L
  N -- Yes --> O[Merge PR
  into main]
  O --> P[release-please
  creates Release PR]
  P --> Q[CI on Release PR]
  Q --> R{CI passes}
  R -- No --> P
  R -- Yes --> S[Merge Release PR
  GitHub Release + tag]
  S --> T[End
  production release ready]
Loading

Flow diagram for the phase completion lifecycle

flowchart TD
  A[Start Phase<br/>features planned] --> B[Development<br/>feat/* branches<br/>target dev]
  B --> C[Integration<br/>merge dev into main]
  C --> D[Release<br/>release-please<br/>Release PR + tag]
  D --> E[Documentation<br/>update PHASE-index.md<br/>update phase docs]
  E --> F[Snapshot<br/>create phase-N<br/>from main]
  F --> G[Phase snapshot workflow<br/>full validation<br/>audit snapshot<br/>annotated tag]
  G --> H[Sync<br/>phase-N to dev<br/>ready for next phase]
  H --> I{Next phase<br/>planned}
  I -- Yes --> B
  I -- No --> J[Project idle]
Loading

File-Level Changes

Change Details Files
Introduce a detailed phase completion workflow reference for how to close out a project phase and manage phase branches, releases, and snapshots.
  • Document the high-level phase lifecycle with ASCII diagram (development, integration, release, documentation, snapshot, sync).
  • Describe step‑by‑step commands for merging dev to main when a phase is feature-complete, including use of GitHub CLI and CI checks.
  • Detail the release process using release-please, including locating the auto-generated PR, triggering CI if needed, merging, and verifying the GitHub release.
  • Provide instructions for updating phase-related documentation files and creating a docs branch for the phase completion update.
  • Describe how to create and protect a phase-N snapshot branch from main and how the phase-snapshot workflow validates and tags snapshots.
  • Explain how to sync the dev branch from a phase branch, either via hard reset or PR, as preparation for the next phase.
  • Include troubleshooting procedures for out-of-sync phase branches, dev/main divergence, and cleaning up old phase snapshot tags.
docs/PHASE-FLOW.md
Add a daily development workflow guide covering branch strategy, local checks, PR creation, CI expectations, and release behavior from main.
  • Define the branching strategy (main, dev, feat/*) and their intended roles.
  • Document the daily cycle for starting work, creating feature branches, committing, and running local lint, format, type-check, and test commands via uv.
  • Describe how to create pull requests targeting dev, required CI checks, and the process for merging to dev using GitHub CLI.
  • Explain how to merge dev into main when a feature is complete and how release-please handles releases from main merges.
  • Specify conventional commit message format and allowed types/scopes for the project.
  • Provide a quick-reference section with common git, CI, and test commands for day-to-day work.
  • Clarify the next planned phase (Ingest Layer / PRP-3) and how it fits into the documented flow (dev → main → release → phase snapshot).
docs/DAILY-FLOW.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jan 26, 2026

Warning

Rate limit exceeded

@w7-mgfcode has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 13 minutes and 42 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

Two new documentation files added detailing ForecastLabAI operational procedures: DAILY-FLOW.md covers branch strategy, daily development cycle, release flow, and commit conventions; PHASE-FLOW.md documents phase completion workflows, lifecycle management, snapshot validation, and troubleshooting guidance.

Changes

Cohort / File(s) Summary
Documentation
docs/DAILY-FLOW.md, docs/PHASE-FLOW.md
Added comprehensive procedural documentation for development workflow (branch strategy, daily cycle, release flow) and phase completion flow (lifecycle, validation, branch protection rules, troubleshooting). Includes shell and GitHub CLI command examples.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Suggested reviewers

  • w7-learn

Poem

🐰 Hops excitedly across the repo
New flows are documented, clear as can be,
Daily routines and phases we see!
With branches and workflows all mapped out,
This rabbit knows what development's about! ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and accurately summarizes the main change: adding two documentation files (DAILY-FLOW and PHASE-FLOW) to the docs directory.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In `@docs/PHASE-FLOW.md`:
- Around line 124-132: Reorder the two sync examples so the safer PR-based
workflow (the gh pr create --base dev --head phase-N --title "sync: update dev
from phase-N") appears first, followed by the destructive approach; keep the
destructive git reset --hard phase-N and git push origin dev --force example but
label it clearly as dangerous (e.g., add "DANGEROUS: force pushes" or similar)
and include a brief warning about disrupting teammates before that snippet;
ensure references to the commands git reset --hard, git push --force and gh pr
create remain unchanged so reviewers can locate the examples.
- Around line 219-243: Add explicit team-coordination warnings before each
destructive command block under the headings "Phase branch behind main", "Dev
diverged from main", and "Régi phase tag törlése": insert a short notice (e.g.,
"⚠️ Csak akkor használd, ha biztos vagy benne, hogy nincs mentetlen munka! /
Coordinate with your team before running destructive commands (force-push, hard
reset, delete).") immediately above the bash fences so readers must acknowledge
the risk before the commands in those sections.
🧹 Nitpick comments (3)
docs/DAILY-FLOW.md (1)

88-88: Consider clarifying why --delete-branch is omitted.

Unlike the feature branch merge at line 70, this merge command doesn't include --delete-branch. While this is correct (since dev is a persistent branch), adding a brief comment would improve clarity for readers who might wonder about the difference.

📝 Suggested clarification
 # CI ellenőrzések után merge
-gh pr merge <PR_NUMBER> --squash
+gh pr merge <PR_NUMBER> --squash  # dev branch marad (persistent)
docs/PHASE-FLOW.md (2)

9-33: Specify language for code block.

The ASCII diagram code block should specify a language identifier (or use text) for better rendering and linting compliance.

📝 Suggested fix
-```
+```text
 ┌─────────────────────────────────────────────────────────────────┐
 │                        PHASE LIFECYCLE                          │

166-193: Specify language for code block.

The markdown checklist code block should specify markdown as the language identifier for better rendering and linting compliance.

📝 Suggested fix
-```markdown
+````markdown
 ## Phase N Completion Checklist
 
 ### Development

Or if nesting is an issue, simply:

-```markdown
+```md

Comment thread docs/PHASE-FLOW.md
Comment on lines +124 to +132
# Szinkronizáld dev-et a phase branch-ről
git checkout dev
git reset --hard phase-N
git push origin dev --force

# VAGY PR-rel (biztonságosabb)
gh pr create --base dev --head phase-N \
--title "sync: update dev from phase-N"
```
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Reconsider ordering: show the safer PR method first.

The destructive git reset --hard + force push approach is presented before the safer PR-based sync. While you note the PR method is "biztonságosabb" (safer), developers often follow the first example they see. Force pushing to dev can disrupt other team members who have that branch checked out and destroys any local uncommitted work.

♻️ Suggested reordering
-# Szinkronizáld dev-et a phase branch-ről
-git checkout dev
-git reset --hard phase-N
-git push origin dev --force
-
-# VAGY PR-rel (biztonságosabb)
+# PR-rel (ajánlott, biztonságos)
 gh pr create --base dev --head phase-N \
   --title "sync: update dev from phase-N"
+
+# VAGY force reset (csak ha biztosan nincs más dolgozó változás)
+# FIGYELEM: Ez törli a local uncommitted változásokat!
+git checkout dev
+git reset --hard phase-N
+git push origin dev --force
🤖 Prompt for AI Agents
In `@docs/PHASE-FLOW.md` around lines 124 - 132, Reorder the two sync examples so
the safer PR-based workflow (the gh pr create --base dev --head phase-N --title
"sync: update dev from phase-N") appears first, followed by the destructive
approach; keep the destructive git reset --hard phase-N and git push origin dev
--force example but label it clearly as dangerous (e.g., add "DANGEROUS: force
pushes" or similar) and include a brief warning about disrupting teammates
before that snippet; ensure references to the commands git reset --hard, git
push --force and gh pr create remain unchanged so reviewers can locate the
examples.

Comment thread docs/PHASE-FLOW.md
Comment on lines +219 to +243
### Phase branch behind main
```bash
# Töröld és hozd újra létre main-ről
git push origin --delete phase-N
git checkout main && git pull
git checkout -b phase-N
git push origin phase-N
```

### Dev diverged from main
```bash
# Reset dev to main
git checkout dev
git reset --hard origin/main
git push origin dev --force
```

### Régi phase tag törlése
```bash
# Töröld a remote taget
git push origin --delete phase-N-snapshot-YYYYMMDD-<sha>

# Töröld a local taget
git tag -d phase-N-snapshot-YYYYMMDD-<sha>
```
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Add warnings about team coordination for destructive operations.

The troubleshooting section documents several destructive operations (force push, branch deletion, hard reset) without warnings about coordinating with the team first. These operations can cause significant disruption if other developers are actively working.

📋 Suggested safety additions
 ## Hibaelhárítás
 
+> ⚠️ **FIGYELEM**: Az alábbi műveletek destructive! Mindig egyeztess a csapattal használat előtt.
+
 ### Phase branch behind main

Additionally, consider adding a note before each destructive command:

 ### Dev diverged from main
 ```bash
+# ⚠️ Csak akkor használd, ha biztos vagy benne, hogy nincs mentetlen munka!
 # Reset dev to main
 git checkout dev
🤖 Prompt for AI Agents
In `@docs/PHASE-FLOW.md` around lines 219 - 243, Add explicit team-coordination
warnings before each destructive command block under the headings "Phase branch
behind main", "Dev diverged from main", and "Régi phase tag törlése": insert a
short notice (e.g., "⚠️ Csak akkor használd, ha biztos vagy benne, hogy nincs
mentetlen munka! / Coordinate with your team before running destructive commands
(force-push, hard reset, delete).") immediately above the bash fences so readers
must acknowledge the risk before the commands in those sections.

External systems send natural keys (store_code, sku) rather than internal
database IDs. The ingest service must resolve these codes to IDs and handle
unknown codes gracefully by rejecting individual rows without failing the
entire batch.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@w7-mgfcode w7-mgfcode closed this Jan 26, 2026
@w7-mgfcode w7-mgfcode deleted the docs/flow-documentation branch January 26, 2026 12:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants