Leave Management Project: Start Guide

Goal

This guide explains how we should proceed on the Leave Management project using:

• Git docs as the source of truth
• Linear as the execution layer
• Telegram as the communication layer
• TUI as the local working and review layer

The aim is to move from planning into the first controlled execution step.

---

1. What we already have

The Leave Management project already has the basic docs skeleton and a rough MVP direction.

Current direction from the docs:

• leave request submission
• approval or rejection
• leave balance tracking
• basic workflow visibility
• simple reporting later, not in MVP

Current project stance:

• planning is in place
• the next step is to confirm the first working slice

---

2. What should happen next

Before implementation starts, we should confirm three things:

1. the exact MVP workflow
2. the user roles involved
3. the source of leave policy/balance data

These are the first decisions that affect the implementation plan.

---

3. Recommended first MVP slice

For the first version, keep the project narrow.

Suggested MVP flow:

1. employee logs in
2. employee submits a leave request
3. manager sees pending requests
4. manager approves or rejects the request
5. the request status is recorded
6. leave balance is updated or displayed consistently

This is enough to prove the core business value.

---

4. What belongs in each tool

Git docs

Use the docs for stable decisions:

• vision
• scope
• requirements
• workflows
• data model
• MVP plan
• open questions

If the project meaning changes, update the docs first.

Linear

Use Linear for executable work:

• planning issues
• implementation tasks
• blockers
• review requests
• completion tracking

If something is actionable, it belongs in Linear.

Telegram

Use Telegram for communication:

• approval requests
• quick confirmations
• short clarifications
• blocker discussion
• progress summaries

If it is conversation, keep it in Telegram.

TUI

Use TUI for local work:

• editing docs
• checking repo structure
• preparing files
• validating changes
• reviewing generated output

If it requires file-level work, use TUI.

---

5. How I should react to Linear changes

When you update Linear, I should treat the change as a signal.

If you approve a task

Meaning:

• the task is accepted
• I can continue to dependent work

What I do next:

• move the project forward
• create the next issue if needed
• update docs only if the task changed the project definition

If you confirm a requirement

Meaning:

• the requirement is now fixed
• implementation can proceed against that decision

What I do next:

• update docs if needed
• break the confirmed requirement into tasks
• continue execution planning

If you change scope

Meaning:

• the project boundary changed
• the release plan may need revision

What I do next:

• update scope and MVP docs
• adjust issue breakdown
• warn about timeline or release impact

If you mark something blocked

Meaning:

• work cannot continue yet

What I do next:

• identify the missing dependency
• pause dependent work
• ask for the needed decision or input

If you request changes in review

Meaning:

• the current work is not ready to close

What I do next:

• revise the task or create follow-up issues
• update docs if the feedback changes the spec
• keep the issue open until the fix is complete

---

6. Recommended initial Linear setup for Leave Management

Create the Linear project:

• Leave Management

Then create the first issues in this order:

1. confirm MVP workflow
2. confirm user roles
3. confirm leave policy source
4. define data model for leave requests and balances
5. implement request submission
6. implement manager review queue
7. implement approve/reject action
8. implement status and balance update

These first issues are enough to start the project cleanly.

---

7. Suggested review gates

Gate 1: plan confirmation

Before implementation, confirm:

• scope
• workflow
• roles
• data source

Gate 2: task approval

For each implementation task, confirm:

• it works as intended
• it matches the docs
• it is ready to close

Gate 3: release review

Before release, confirm:

• the end-to-end leave flow works
• docs are current
• no blocking open questions remain

---

8. My recommendation for the very next step

The best next step is to confirm the MVP workflow in one short decision.

Recommended decision to confirm:

• Is the first release only for employee request + manager approve/reject + balance view?

If yes, I can then help break the Leave Management project into a clean Linear backlog and keep the docs aligned.

---

9. Short version

• You confirm the MVP direction.
• I turn it into docs and Linear tasks.
• Linear tracks execution.
• Telegram handles quick decisions.
• TUI handles file work and checks.

That is the cleanest way to proceed.