Skip to main content

Step 5 — Code — Git Repository

Once your BRD, SRD, and FSD are approved (see Specification — FSD & SRD), the project moves through three phases that take it from approved spec to an actual codebase: Plan & Task, Build, and Code – Git.

Phase 3 — Plan & Task​

Purpose: Convert your approved specifications into an actionable development plan and task breakdown — the execution roadmap for the Build phase.

This phase has two components:

  • Development Plan — Sprint timelines, milestones, and phased deliverables
  • Development Tasks — Granular, actionable items for individual developers

Generating the Development Plan​

  1. After your specs are approved, proceed to Phase 3 – Plan & Task.
  2. Open the Development Plan tab.
  3. Click "Generate Plan" to create the sprint plan and phased execution timeline.
  4. Once generated: Preview, Edit, Download, or Regenerate as needed.

Generating Development Tasks​

  1. After finalizing the plan, navigate to the Development Tasks tab.
  2. Click "Generate Tasks" — DeX automatically creates actionable tasks based on the approved plan.
  3. Once generated: Preview, Edit, Download, or Regenerate if the plan changes.

🗓️ Ensure the Development Plan is reviewed and approved before generating tasks — tasks are derived directly from the plan structure, so changes to the plan after task generation will require regeneration.

Worked Example — Contractor Sync Sprint Plan (excerpt)​

SprintFocusKey Deliverables
Sprint 1Core mobile app shell + authFlutter app skeleton, JWT login, site assignment data model
Sprint 2GeofencingPostGIS site radius validation, GPS capture, clock-in/out API
Sprint 3Facial verificationCamera capture flow, verification service integration, retry/flag logic
Sprint 4Supervisor dashboardReal-time on-site status view, flagged-attempt review screen
Sprint 5Payroll export + hardeningAttendance export format, security review, QA pass

Phase 4 — Build​

Purpose: Compile and prepare the application for development execution based on the approved plan and tasks.

🔒 Access Control Notice: Phases 4 through 7 (Build, Code, QA, Deploy) are locked by default for standard users. This ensures governance, security, and proper authorization before compilation and deployment activities begin.

Requesting Build Access​

  1. Click "Request Build Access" within Phase 4.
  2. This sends a notification to the Platform Administrator.
  3. The administrator reviews and grants permissions for Build, Code, QA, and Deployment stages — this may include provisioning VM access for your project workspace, depending on your organization's setup.
  4. Once approved, Phase 4 becomes fully accessible.

⚠️ Build Access is an organization-level governance gate, not a per-user toggle you control yourself. If you're blocked here, contact your Platform Administrator rather than your project team.

Build Execution​

After access is granted, select your build strategy:

Build TypeDescriptionWhen to Use
Clean Build (From Scratch)Compiles the entire project using the FSD, SRD, and development planNew projects or full rebuilds
Addon Build (Incremental)Applies custom instructions; builds new features or patches existing files on top of an existing buildFeature additions or iterative updates

Steps:

  1. Select your preferred build type.
  2. Click "Start Colakin CLI Build" to initiate the build process.
  3. Monitor build progress in the terminal output panel.
  4. On successful completion, Phase 5 – Code becomes unlocked.

Worked Example — Contractor Sync Addon Build​

After the initial Clean Build shipped Sprints 1–4, a new requirement came in mid-project: supervisors wanted a shift-handover note field attached to each clock-out. Rather than rebuilding from scratch:

  1. The team selected Addon Build (Incremental).
  2. They provided a custom instruction: "Add an optional text field to the clock-out flow for a shift-handover note, visible on the supervisor dashboard."
  3. DeX patched the relevant FSD-derived files (clock-out endpoint, mobile clock-out screen, dashboard view) without touching the rest of the codebase.
  4. The build completed and Phase 5 reflected only the changed files.

This is the core advantage of the Addon Build path — it lets you keep iterating on a live project without re-running a full rebuild for every small feature.

Phase 5 — Code – Git Repository​

Purpose: Integrate the compiled application into a Git repository and provide a local workspace code editor for developers to review, refine, and manage the generated codebase.

Steps​

  1. Access the Local Files tab to browse backend and frontend directory structures.
  2. Use the GitHub Repo tab to synchronize code with your connected repository.
  3. Use the built-in file search to locate specific files quickly.
  4. Open any file in the inline editor to view its contents.
  5. Perform file operations as needed:
    • Modify existing files
    • Create new files
    • Delete files that are no longer needed

🔗 Ensure your GitHub repository is connected before attempting to sync. Repository settings can be configured in your account preferences.

Worked Example — Contractor Sync Git Sync​

For Contractor Sync, the team connected a GitHub repository under their organization (org/contractor-sync) during Phase 5. Backend (FastAPI) and frontend (Flutter) directories were synced as separate top-level folders, and the team used the inline editor to manually tune the PostGIS geofence radius default before pushing the change upstream via the GitHub Repo tab.

What's Next​

➡️ QA — Outcome — Run automated tests against the compiled application before deployment.