DEV Community: kanta13jp1

Pushing from git worktree branches to main — Multi-Instance Conflict Recovery Guide

kanta13jp1 — Sun, 19 Apr 2026 10:51:05 +0000

Pushing from git worktree branches to main

TL;DR

When running multiple Claude Code instances, pushing from each instance's wip branch directly to origin/main is the simplest approach. Conflicts resolve with a single git pull --rebase origin main command.

Setup: Worktree Layout

my_web_app/
  .claude/worktrees/
    instance-ps1/    ← branch: claude/ps1-wip
    instance-ps2/    ← branch: claude/ps2-wip
    instance-vscode/ ← branch: claude/vscode-wip

Each instance works exclusively on its wip branch and merges into origin/main only at push time.

3 Push Patterns

Pattern 1: `HEAD:main` (recommended)

git push origin HEAD:main

Pushes the currently checked-out branch to origin/main. No need to remember branch names.

Pattern 2: Explicit branch name

git push origin claude/ps1-wip:main

Better for scripts and CI where HEAD might be ambiguous.

Pattern 3: Push from outside the worktree

git -C .claude/worktrees/instance-ps1 push origin HEAD:main

Useful when pushing another instance's changes from the main repo directory.

Conflict Recovery

When two instances push simultaneously, the second one gets rejected:

! [rejected]        claude/ps1-wip -> main (non-fast-forward)
error: failed to push some refs
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Standard recovery (single command):

git pull --rebase origin main && git push origin HEAD:main

Using rebase avoids merge commits — keeps the log clean.

Common Conflict Patterns and Fixes

Simultaneous ROADMAP.md appends

docs/GROWTH_STRATEGY_ROADMAP.md gets appended by every instance at session end — it's the most conflict-prone file.

Fix: Assign a fixed section per instance:

### PS版#1 Session Log

### PS版#2 Session Log

### VSCode Session Log

Instances never touch each other's sections, so rebase auto-merges succeed most of the time.

Migration file timestamp collision

20260419220000_seed_foo.sql   ← created by PS#1
20260419220000_seed_bar.sql   ← created by Win at the same second

Identical timestamps cause duplicate key errors in Supabase deploy.

Fix: Before creating a migration file, check the current max timestamp for the day:

ls supabase/migrations/ | grep $(date +%Y%m%d) | sort | tail -1
# → 20260419220000_seed_foo.sql

# New file: +10 seconds
touch supabase/migrations/20260419220010_seed_bar.sql

wip branch far behind main

After a long session, origin/main might be 20+ commits ahead, increasing rebase conflicts.

Diagnosis:

git log --oneline claude/ps1-wip..origin/main | wc -l
# If 20+, inspect before rebasing

Fix: If 3+ conflicts, switch to merge:

git rebase --abort
git fetch origin
git merge origin/main  # accept the merge commit
# resolve conflicts manually
git push origin HEAD:main

Summary

Situation	Command
Normal push	`git push origin HEAD:main`
Recovery after rejection	`git pull --rebase origin main && git push origin HEAD:main`
Heavy conflicts	`git rebase --abort && git merge origin/main` → manual resolution
Check migration timestamp	`ls supabase/migrations/ \

Conflicts in multi-instance parallel development can't be completely eliminated. But by consistently using {% raw %}rebase + direct push to main, you can maintain a state where any conflict is recoverable in under 30 seconds.

Building in public: https://my-web-app-b67f4.web.app/

ClaudeCode #git #buildinpublic

Running 10 Claude Code Instances in Parallel — git worktree Isolation Design

kanta13jp1 — Sun, 19 Apr 2026 10:41:46 +0000

Running 10 Claude Code Instances in Parallel

The Problem: git stash Destroys Other Instances' Work

Running multiple Claude Code instances against the same repository causes silent data loss:

Instance A: editing lib/pages/home_page.dart (uncommitted)
Instance B: runs git pull --rebase
            → A's uncommitted changes get swept up in the rebase and lost

Instance C: runs git stash
            → Since all instances share the same workdir,
              A and B's changes end up in C's stash

Root cause: all instances share the same working directory.

The Fix: Dedicated Worktree per Instance

git worktree add .claude/worktrees/instance-ps1 -b claude/ps1-wip
git worktree add .claude/worktrees/instance-ps2 -b claude/ps2-wip
git worktree add .claude/worktrees/instance-vscode -b claude/vscode-wip
git worktree add .claude/worktrees/instance-win -b claude/win-wip

Each instance operates exclusively in its own worktree. git stash and git pull --rebase in one instance have zero effect on others.

10-Instance Role Assignment

PS#1     → .claude/worktrees/instance-ps1   (CI/WF health monitoring)
PS#2     → .claude/worktrees/instance-ps2   (blog post dispatch)
PS#3     → .claude/worktrees/instance-ps3   (AI university content)
PS#4     → .claude/worktrees/instance-ps4   (competitor monitoring)
PS#5     → .claude/worktrees/instance-ps5   (on-call bug fixes)
PS#6     → .claude/worktrees/instance-ps6   (batch jobs / horse racing)
VSCode   → .claude/worktrees/instance-vscode (UI / design)
Windows  → .claude/worktrees/instance-win   (AI university / migrations)
WEB      → no worktree needed (GitHub MCP only)
Mobile   → no worktree needed (GitHub MCP only)

Setup Script

#!/bin/bash
# .claude/scripts/setup-instance-worktree.sh
set -e

INSTANCE=$1
REPO_ROOT=$(git rev-parse --show-toplevel)
WORKTREE_DIR="$REPO_ROOT/.claude/worktrees/instance-$INSTANCE"
BRANCH="claude/${INSTANCE}-wip"

if [ -d "$WORKTREE_DIR" ]; then
  echo "worktree already exists: $WORKTREE_DIR"
  exit 0
fi

git worktree add "$WORKTREE_DIR" -b "$BRANCH" 2>/dev/null || \
  git worktree add "$WORKTREE_DIR" "$BRANCH"

echo "created: $WORKTREE_DIR (branch: $BRANCH)"

Usage:

bash .claude/scripts/setup-instance-worktree.sh ps1
bash .claude/scripts/setup-instance-worktree.sh vscode

Pushing to main

Each instance pushes its wip branch tip to main:

cd .claude/worktrees/instance-ps1

git add docs/GROWTH_STRATEGY_ROADMAP.md
git commit -m "ci: Rule17 health check"

git pull --rebase origin main
git push origin claude/ps1-wip:main

When two instances push simultaneously, the second will get a "behind remote" rejection. Recovery:

git pull --rebase origin main   # fast-forward or resolve conflicts
git push origin claude/ps1-wip:main

Registering Worktrees in .git/info/exclude

Worktrees are git internals — do not add them to .gitignore (that would break git worktree list). Instead use the local-only exclude file:

# .git/info/exclude
.claude/worktrees/

List active worktrees at any time:

git worktree list
# /path/to/my_web_app                    abc1234 [main]
# /path/to/.claude/worktrees/instance-ps1  def5678 [claude/ps1-wip]
# /path/to/.claude/worktrees/instance-ps2  ghi9012 [claude/ps2-wip]

Results

Problem	Before	After
stash interference	Changes from other instances disappear	Each instance has its own stash
pull --rebase	Sweeps up other instances' uncommitted work	Only affects the local wip branch
Parallel push	Collision / overwrite risk	Always rebase-clean before push
Debugging	Unclear which instance made a change	Traceable by wip branch name

Key Rules

Never work in the main repo directory — it's push target only
git stash is banned — WIP commit instead (git commit -m "WIP")
commit before pull --rebase — staged-only changes can still be lost
Edit → commit → push in a single bash invoke — prevents linter revert interference

Conclusion

git worktree is the standard solution for multiple processes sharing the same repository. For Claude Code's autonomous multi-instance model, it's not optional — it's the design. One worktree + wip branch per instance eliminates the entire class of "my changes disappeared" incidents.

Building in public: https://my-web-app-b67f4.web.app/

ClaudeCode #git #buildinpublic

GitHub Actions Concurrency Trap — cancel-in-progress: false Still Drops Queued Runs

kanta13jp1 — Sun, 19 Apr 2026 10:34:58 +0000

GitHub Actions Concurrency Trap

TL;DR

cancel-in-progress: false only protects running jobs. Queued jobs are still cancelled by newer runs.

The Problem: 6 Deploys Cancelled in a Row

deploy-prod cancelled 2026-04-19T10:00:59
deploy-prod cancelled 2026-04-19T10:02:30
deploy-prod cancelled 2026-04-19T10:04:03
deploy-prod cancelled 2026-04-19T10:07:30
deploy-prod cancelled 2026-04-19T10:08:41
deploy-prod cancelled 2026-04-19T10:08:56
deploy-prod success  2026-04-19T10:09:34  ← only the last one ran

The config said cancel-in-progress: false. So why all the cancellations?

How GitHub Actions Concurrency Actually Works

concurrency:
  group: deploy-prod
  cancel-in-progress: false

What this setting actually controls:

Job State	cancel-in-progress: true	cancel-in-progress: false
Currently running	Gets cancelled	Protected ✅
Queued (waiting)	Gets cancelled	Still gets cancelled ⚠️

The key insight: cancel-in-progress only governs the running job. The queue slot holds exactly one run — any newer run evicts the previous queued run unconditionally.

The Mechanics

GitHub Actions concurrency groups enforce:

At most 1 running job per group
At most 1 queued job per group
When a new run arrives:
- If something is running → respect cancel-in-progress
- If something is queued → always cancel it, new run takes the queue slot

Think of the queue as a single reservation: it always reflects the most recent pending run.

What Happened in Our Case

A blog-publish workflow generated 8 commits in 10 minutes → 8 deploy-prod triggers:

push #1 → deploy A: running
push #2 → deploy B: queued   (waits for A)
push #3 → deploy C: queued   (cancels B, C takes queue)
push #4 → deploy D: queued   (cancels C, D takes queue)
...
push #8 → deploy H: queued   (last one standing)
deploy A completes → deploy H: runs → success

Result: #2–#7 cancelled (6 runs), #1 and #8 executed.

Is This a Problem?

Not in our case. The blog-publish commits only flip published: true in a frontmatter file. Deploy #8 reflects the final state — skipping #2–#7 doesn't matter.

When it would be a problem:

# DB migrations that must run in order:
# migration A → migration B → migration C
# If B and C get queue-cancelled, only A applies — broken schema

Solutions

Option 1: Keep as-is (fine when final state is what matters)

concurrency:
  group: deploy-prod
  cancel-in-progress: false

Works for frontend deploys, static asset updates — anything where "latest wins."

Option 2: Unique group per commit

concurrency:
  group: ${{ github.sha }}
  cancel-in-progress: false

Every commit gets its own group → every run executes. Watch your resource usage.

Option 3: Filter out noisy triggers

on:
  push:
    branches: [main]
    paths:
      - 'lib/**'
      - 'supabase/functions/**'
      - '!docs/blog-drafts/**'  # skip published:true marker commits

The root fix: don't trigger deploys for commits that don't need them.

Summary

Setting	Protects Running	Protects Queued	Use When
`cancel-in-progress: true`	❌	❌	Fast iteration, interrupts OK
`cancel-in-progress: false`	✅	❌	Frontend deploy (latest wins)
`group: ${{ github.sha }}`	—	✅ (all run)	DB migrations, ordered deploys

cancel-in-progress: false is commonly misread as "all runs will execute." It means "don't interrupt the run in progress." If you see mass cancellations, check whether the final deployed state is still correct before panicking.

Building in public: https://my-web-app-b67f4.web.app/

GitHubActions #CICD #buildinpublic

Complete Error Handling Patterns for Supabase Edge Functions — 4-Stage Fallback Design

kanta13jp1 — Sun, 19 Apr 2026 10:23:04 +0000

Complete Error Handling Patterns for Supabase Edge Functions

Why Error Handling Matters

Edge Functions have three error sources: external APIs, database access, and user input. Without proper handling:

Flutter clients crash on unexpected 500s
Supabase logs fill up with noise
Debugging takes forever

The 4-Stage Fallback Template

Deno.serve(async (req: Request) => {
  // Stage 1: CORS preflight
  if (req.method === 'OPTIONS') {
    return new Response(null, { headers: corsHeaders, status: 204 });
  }

  try {
    // Stage 2: Input validation
    const { action, ...params } = await parseBody(req);
    if (!action) {
      return errorResponse(400, 'action is required');
    }

    // Stage 3: Routing
    switch (action) {
      case 'get': return await handleGet(params);
      case 'upsert': return await handleUpsert(params);
      default: return errorResponse(400, `Unknown action: ${action}`);
    }
  } catch (err) {
    // Stage 4: Unexpected errors
    console.error('[EF Error]', err);
    return errorResponse(500, 'Internal server error');
  }
});

Input Validation

async function parseBody(req: Request): Promise<Record<string, unknown>> {
  const contentType = req.headers.get('content-type') ?? '';

  if (contentType.includes('application/json')) {
    try {
      return await req.json();
    } catch {
      throw new ValidationError('Invalid JSON body');
    }
  }

  if (contentType.includes('application/x-www-form-urlencoded')) {
    const text = await req.text();
    return Object.fromEntries(new URLSearchParams(text));
  }

  return {};
}

class ValidationError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'ValidationError';
  }
}

Unified Error Response Format

function errorResponse(status: number, message: string, details?: unknown): Response {
  return new Response(
    JSON.stringify({
      error: message,
      details: details ?? null,
      timestamp: new Date().toISOString(),
    }),
    {
      status,
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
    }
  );
}

function successResponse(data: unknown, status = 200): Response {
  return new Response(
    JSON.stringify({ data, success: true }),
    {
      status,
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
    }
  );
}

Supabase Client Errors

async function handleGet(params: Record<string, unknown>): Promise<Response> {
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  );

  const { data, error } = await supabase
    .from('my_table')
    .select('*')
    .eq('id', params.id);

  if (error) {
    // Branch on PostgreSQL error code
    if (error.code === '42P01') { // table doesn't exist
      return errorResponse(500, 'Database schema error', error);
    }
    if (error.code === '23505') { // unique violation
      return errorResponse(409, 'Duplicate entry', error.details);
    }
    return errorResponse(500, error.message, error);
  }

  return successResponse(data);
}

External API Calls with Timeout

async function fetchWithTimeout(url: string, options: RequestInit, timeoutMs = 10000): Promise<Response> {
  const controller = new AbortController();
  const timeoutId = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const response = await fetch(url, {
      ...options,
      signal: controller.signal,
    });
    clearTimeout(timeoutId);
    return response;
  } catch (err) {
    clearTimeout(timeoutId);
    if (err instanceof Error && err.name === 'AbortError') {
      throw new Error(`Request timed out after ${timeoutMs}ms`);
    }
    throw err;
  }
}

Keeping deno lint at Zero Errors

Common violations:

// ❌ no-explicit-any
async function handle(data: any) {}

// ✅ unknown + type guard
async function handle(data: unknown) {
  if (typeof data !== 'object' || data === null) throw new Error('Invalid data');
  const typed = data as Record<string, unknown>;
}

// ❌ prefer-const
let result = await fetch(url);

// ✅
const result = await fetch(url);

Summary

Layer	Defense
Input	JSON/form support + type validation
Routing	action switch + unknown action → 400
DB	Branch on error.code
External API	Timeout + AbortController
Unexpected	try/catch → 500

Applying this 5-layer pattern across all hub EFs dramatically cuts debugging time in production.

Building in public: https://my-web-app-b67f4.web.app/

Supabase #Deno #TypeScript #buildinpublic #webdev

Building an MS Project-Style Gantt Chart in Flutter Web — CustomPaint with Synchronized Scrolling

kanta13jp1 — Sun, 19 Apr 2026 10:23:02 +0000

Building an MS Project-Style Gantt Chart in Flutter Web

The Goal

Visualize WBS (Work Breakdown Structure) progress with a synchronized task list on the left and a scrollable timeline on the right — like MS Project, but in Flutter Web.

Architecture

Row(
  children: [
    // Left pane: task names and assignees (fixed width)
    SizedBox(width: 300, child: TaskListPane()),
    // Right pane: timeline bars (horizontally scrollable)
    Expanded(child: TimelinePane()),
  ],
)

Two ScrollController instances linked together keep vertical scroll synchronized between panes.

Implementation

Synchronized Scrolling

class _GanttChartPageState extends State<GanttChartPage> {
  final _leftVertical = ScrollController();
  final _rightVertical = ScrollController();

  @override
  void initState() {
    super.initState();
    _leftVertical.addListener(() {
      if (_rightVertical.offset != _leftVertical.offset) {
        _rightVertical.jumpTo(_leftVertical.offset);
      }
    });
    _rightVertical.addListener(() {
      if (_leftVertical.offset != _rightVertical.offset) {
        _leftVertical.jumpTo(_rightVertical.offset);
      }
    });
  }
}

Drawing Gantt Bars with CustomPaint

class GanttBarPainter extends CustomPainter {
  final List<WbsTask> tasks;
  final DateTime startDate;
  final double dayWidth;

  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint();

    for (int i = 0; i < tasks.length; i++) {
      final task = tasks[i];
      final y = i * 40.0 + 8;
      final startX = task.startDate.difference(startDate).inDays * dayWidth;
      final barWidth = task.duration.inDays * dayWidth;

      // Background bar
      paint.color = _progressColor(task.progressRate).withAlpha(80);
      canvas.drawRRect(
        RRect.fromRectAndRadius(
          Rect.fromLTWH(startX, y, barWidth, 24),
          const Radius.circular(4),
        ),
        paint,
      );

      // Progress fill
      paint.color = _progressColor(task.progressRate);
      canvas.drawRRect(
        RRect.fromRectAndRadius(
          Rect.fromLTWH(startX, y, barWidth * task.progressRate / 100, 24),
          const Radius.circular(4),
        ),
        paint,
      );
    }
  }

  Color _progressColor(int progress) {
    if (progress >= 100) return const Color(0xFF4CAF50); // done: green
    if (progress >= 50) return const Color(0xFFFF9800);  // in progress: orange
    return const Color(0xFFFF5722);                       // behind: red
  }

  @override
  bool shouldRepaint(GanttBarPainter old) =>
      old.tasks != tasks || old.startDate != startDate;
}

WbsTask Model

class WbsTask {
  final String id;
  final String title;
  final String? assignee;
  final DateTime startDate;
  final Duration duration;
  final int progressRate; // 0-100
  final List<String> dependencies;
}

Supabase Schema

CREATE TABLE wbs_tasks (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  title text NOT NULL,
  start_date date NOT NULL,
  end_date date NOT NULL,
  progress_rate int DEFAULT 0 CHECK (progress_rate BETWEEN 0 AND 100),
  dependencies uuid[],
  user_id uuid REFERENCES auth.users(id)
);

Gotchas

shouldRepaint performance

Returning true always causes per-frame repaints. Check if data actually changed:

@override
bool shouldRepaint(GanttBarPainter old) =>
    old.tasks != tasks || old.startDate != startDate;

Alignment between header and bars

The date header (month/day labels) and the actual bar positions must use the same startDate and dayWidth constant. Compute both in the parent widget and pass them down.

Conclusion

Flutter Web's CustomPaint handles complex visualizations that existing widgets can't. For Gantt charts with custom grid layouts, painting from scratch gives you full control — and the performance is fine for typical WBS sizes (< 200 tasks).

Building in public: https://my-web-app-b67f4.web.app/

Flutter #CustomPaint #buildinpublic #WBS

Complete Error Handling Patterns for Supabase Edge Functions — 4-Stage Fallback Design

kanta13jp1 — Sun, 19 Apr 2026 10:05:35 +0000

Complete Error Handling Patterns for Supabase Edge Functions

Why Error Handling Matters

Edge Functions have three error sources: external APIs, database access, and user input. Without proper handling:

Flutter clients crash on unexpected 500s
Supabase logs fill up with noise
Debugging takes forever

The 4-Stage Fallback Template

Deno.serve(async (req: Request) => {
  // Stage 1: CORS preflight
  if (req.method === 'OPTIONS') {
    return new Response(null, { headers: corsHeaders, status: 204 });
  }

  try {
    // Stage 2: Input validation
    const { action, ...params } = await parseBody(req);
    if (!action) {
      return errorResponse(400, 'action is required');
    }

    // Stage 3: Routing
    switch (action) {
      case 'get': return await handleGet(params);
      case 'upsert': return await handleUpsert(params);
      default: return errorResponse(400, `Unknown action: ${action}`);
    }
  } catch (err) {
    // Stage 4: Unexpected errors
    console.error('[EF Error]', err);
    return errorResponse(500, 'Internal server error');
  }
});

Input Validation

async function parseBody(req: Request): Promise<Record<string, unknown>> {
  const contentType = req.headers.get('content-type') ?? '';

  if (contentType.includes('application/json')) {
    try {
      return await req.json();
    } catch {
      throw new ValidationError('Invalid JSON body');
    }
  }

  if (contentType.includes('application/x-www-form-urlencoded')) {
    const text = await req.text();
    return Object.fromEntries(new URLSearchParams(text));
  }

  return {};
}

class ValidationError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'ValidationError';
  }
}

Unified Error Response Format

function errorResponse(status: number, message: string, details?: unknown): Response {
  return new Response(
    JSON.stringify({
      error: message,
      details: details ?? null,
      timestamp: new Date().toISOString(),
    }),
    {
      status,
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
    }
  );
}

function successResponse(data: unknown, status = 200): Response {
  return new Response(
    JSON.stringify({ data, success: true }),
    {
      status,
      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
    }
  );
}

Supabase Client Errors

async function handleGet(params: Record<string, unknown>): Promise<Response> {
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  );

  const { data, error } = await supabase
    .from('my_table')
    .select('*')
    .eq('id', params.id);

  if (error) {
    // Branch on PostgreSQL error code
    if (error.code === '42P01') { // table doesn't exist
      return errorResponse(500, 'Database schema error', error);
    }
    if (error.code === '23505') { // unique violation
      return errorResponse(409, 'Duplicate entry', error.details);
    }
    return errorResponse(500, error.message, error);
  }

  return successResponse(data);
}

External API Calls with Timeout

async function fetchWithTimeout(url: string, options: RequestInit, timeoutMs = 10000): Promise<Response> {
  const controller = new AbortController();
  const timeoutId = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const response = await fetch(url, {
      ...options,
      signal: controller.signal,
    });
    clearTimeout(timeoutId);
    return response;
  } catch (err) {
    clearTimeout(timeoutId);
    if (err instanceof Error && err.name === 'AbortError') {
      throw new Error(`Request timed out after ${timeoutMs}ms`);
    }
    throw err;
  }
}

Keeping deno lint at Zero Errors

Common violations:

// ❌ no-explicit-any
async function handle(data: any) {}

// ✅ unknown + type guard
async function handle(data: unknown) {
  if (typeof data !== 'object' || data === null) throw new Error('Invalid data');
  const typed = data as Record<string, unknown>;
}

// ❌ prefer-const
let result = await fetch(url);

// ✅
const result = await fetch(url);

Summary

Layer	Defense
Input	JSON/form support + type validation
Routing	action switch + unknown action → 400
DB	Branch on error.code
External API	Timeout + AbortController
Unexpected	try/catch → 500

Applying this 5-layer pattern across all hub EFs dramatically cuts debugging time in production.

Building in public: https://my-web-app-b67f4.web.app/

Supabase #Deno #TypeScript #buildinpublic #webdev

Building an MS Project-Style Gantt Chart in Flutter Web — CustomPaint with Synchronized Scrolling

kanta13jp1 — Sun, 19 Apr 2026 10:02:54 +0000

Building an MS Project-Style Gantt Chart in Flutter Web

The Goal

Visualize WBS (Work Breakdown Structure) progress with a synchronized task list on the left and a scrollable timeline on the right — like MS Project, but in Flutter Web.

Architecture

Row(
  children: [
    // Left pane: task names and assignees (fixed width)
    SizedBox(width: 300, child: TaskListPane()),
    // Right pane: timeline bars (horizontally scrollable)
    Expanded(child: TimelinePane()),
  ],
)

Two ScrollController instances linked together keep vertical scroll synchronized between panes.

Implementation

Synchronized Scrolling

class _GanttChartPageState extends State<GanttChartPage> {
  final _leftVertical = ScrollController();
  final _rightVertical = ScrollController();

  @override
  void initState() {
    super.initState();
    _leftVertical.addListener(() {
      if (_rightVertical.offset != _leftVertical.offset) {
        _rightVertical.jumpTo(_leftVertical.offset);
      }
    });
    _rightVertical.addListener(() {
      if (_leftVertical.offset != _rightVertical.offset) {
        _leftVertical.jumpTo(_rightVertical.offset);
      }
    });
  }
}

Drawing Gantt Bars with CustomPaint

class GanttBarPainter extends CustomPainter {
  final List<WbsTask> tasks;
  final DateTime startDate;
  final double dayWidth;

  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint();

    for (int i = 0; i < tasks.length; i++) {
      final task = tasks[i];
      final y = i * 40.0 + 8;
      final startX = task.startDate.difference(startDate).inDays * dayWidth;
      final barWidth = task.duration.inDays * dayWidth;

      // Background bar
      paint.color = _progressColor(task.progressRate).withAlpha(80);
      canvas.drawRRect(
        RRect.fromRectAndRadius(
          Rect.fromLTWH(startX, y, barWidth, 24),
          const Radius.circular(4),
        ),
        paint,
      );

      // Progress fill
      paint.color = _progressColor(task.progressRate);
      canvas.drawRRect(
        RRect.fromRectAndRadius(
          Rect.fromLTWH(startX, y, barWidth * task.progressRate / 100, 24),
          const Radius.circular(4),
        ),
        paint,
      );
    }
  }

  Color _progressColor(int progress) {
    if (progress >= 100) return const Color(0xFF4CAF50); // done: green
    if (progress >= 50) return const Color(0xFFFF9800);  // in progress: orange
    return const Color(0xFFFF5722);                       // behind: red
  }

  @override
  bool shouldRepaint(GanttBarPainter old) =>
      old.tasks != tasks || old.startDate != startDate;
}

WbsTask Model

class WbsTask {
  final String id;
  final String title;
  final String? assignee;
  final DateTime startDate;
  final Duration duration;
  final int progressRate; // 0-100
  final List<String> dependencies;
}

Supabase Schema

CREATE TABLE wbs_tasks (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  title text NOT NULL,
  start_date date NOT NULL,
  end_date date NOT NULL,
  progress_rate int DEFAULT 0 CHECK (progress_rate BETWEEN 0 AND 100),
  dependencies uuid[],
  user_id uuid REFERENCES auth.users(id)
);

Gotchas

shouldRepaint performance

Returning true always causes per-frame repaints. Check if data actually changed:

@override
bool shouldRepaint(GanttBarPainter old) =>
    old.tasks != tasks || old.startDate != startDate;

Alignment between header and bars

The date header (month/day labels) and the actual bar positions must use the same startDate and dayWidth constant. Compute both in the parent widget and pass them down.

Conclusion

Building in public: https://my-web-app-b67f4.web.app/

Flutter #CustomPaint #buildinpublic #WBS

Cutting a 26-Minute Supabase Batch Job to Near Zero — The prev_fetched Flag Pattern

kanta13jp1 — Sun, 19 Apr 2026 10:00:14 +0000

Cutting a 26-Minute Supabase Batch Job to Near Zero

The Problem

A horse-racing prediction batch job was taking 26 minutes on every run. The culprit: re-fetching historical race data for every horse on every run — even for horses we'd already fetched data for.

The data doesn't change. Why keep re-fetching?

The Fix: A Single Boolean Column

ALTER TABLE horse_entries
  ADD COLUMN prev_history_fetched boolean DEFAULT false;

Python batch:

def fetch_horse_histories(conn, race_id: int) -> None:
    cur = conn.cursor()

    # Only fetch unfetched horses
    cur.execute("""
        SELECT he.id, he.horse_id
        FROM horse_entries he
        WHERE he.race_id = %s
          AND he.prev_history_fetched = false
    """, (race_id,))
    entries = cur.fetchall()

    for entry_id, horse_id in entries:
        try:
            history = scrape_previous_race(horse_id)
            upsert_history(conn, horse_id, history)
        except Exception as e:
            print(f"Horse {horse_id} 404/skip: {e}")
        finally:
            # Mark as fetched regardless of success/failure
            cur.execute("""
                UPDATE horse_entries
                SET prev_history_fetched = true
                WHERE id = %s
            """, (entry_id,))
            conn.commit()

Key insight: mark as fetched even on 404 errors. A horse that doesn't exist won't exist next run either — no point retrying.

Results

Run	Before	After
First run	26 min	26 min (same)
Second run onward	26 min	~0 sec
404 horses retried	Every run	Never

Generalizing the Pattern

Any "fetch once, never changes" data benefits from this pattern:

ALTER TABLE <table>
  ADD COLUMN <field>_fetched boolean DEFAULT false,
  ADD COLUMN <field>_fetched_at timestamptz;

Criteria:

Data is idempotent (same input → same result)
Re-fetching is expensive or slow
Failures don't need retries (or you want explicit retry logic)

For data that does need refreshing, add an expiry:

WHERE NOT prev_history_fetched
   OR prev_history_fetched_at < NOW() - INTERVAL '30 days'

Conclusion

"Process everything every run" is a common batch antipattern. One boolean column makes subsequent runs instant. The cost is a single extra column and one UPDATE per row on first fetch.

Building in public: https://my-web-app-b67f4.web.app/

Supabase #PostgreSQL #Python #buildinpublic

Adding AI Tag Suggestions to Flutter Notes — Free Groq API for Real-Time Tagging

kanta13jp1 — Sun, 19 Apr 2026 09:59:17 +0000

Adding AI Tag Suggestions to Flutter Notes

The Problem with Manual Tagging

After writing a note, deciding which tags to apply is cognitive overhead. You've just finished organizing your thoughts — now you have to switch mental modes to classify them. AI can handle this automatically.

Architecture Choice

Rather than creating a new Supabase Edge Function, I reused the existing ai-hub EF's provider.chat action:

Flutter → AIService.suggestTags() → ai-hub:provider.chat (Groq llama-3.3-70b) → TagSuggestion

Groq's llama-3.3-70b has a free tier and responds in under 100ms — perfect for lightweight tasks like tag generation.

Implementation

TagSuggestion Model

class TagSuggestion {
  final List<String> tags;
  final String category;
  final String reason;

  const TagSuggestion({
    required this.tags,
    required this.category,
    required this.reason,
  });

  factory TagSuggestion.fromJson(Map<String, dynamic> json) => TagSuggestion(
    tags: List<String>.from(json['tags'] ?? []),
    category: json['category'] ?? '',
    reason: json['reason'] ?? '',
  );
}

AIService.suggestTags()

Future<TagSuggestion> suggestTags({
  required String content,
  String? title,
}) async {
  final prompt = '''
Suggest 5-10 relevant tags for the following note.
Title: ${title ?? '(none)'}
Content: $content

Respond in JSON:
{
  "tags": ["tag1", "tag2", ...],
  "category": "category name",
  "reason": "why these tags"
}
''';

  final response = await _callAiHub(
    action: 'provider.chat',
    provider: 'groq',
    model: 'llama-3.3-70b-versatile',
    prompt: prompt,
  );

  // Strip code blocks if present
  final cleaned = response['content']
    .replaceAll(RegExp(r'```

json\s*'), '')
    .replaceAll(RegExp(r'

```\s*'), '')
    .trim();

  return TagSuggestion.fromJson(json.decode(cleaned));
}

UI Page

class AiSuggestTagsPage extends StatefulWidget {
  const AiSuggestTagsPage({super.key});
}

class _AiSuggestTagsPageState extends State<AiSuggestTagsPage> {
  final _aiService = AIService();
  TagSuggestion? _suggestion;
  bool _isLoading = false;

  Future<void> _suggestTags() async {
    setState(() => _isLoading = true);
    try {
      final result = await _aiService.suggestTags(
        content: _controller.text.trim(),
      );
      setState(() => _suggestion = result);
    } finally {
      setState(() => _isLoading = false);
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('AI Tag Suggestions')),
      body: Column(
        children: [
          TextField(controller: _controller, maxLines: 5),
          if (_isLoading) const CircularProgressIndicator(),
          if (_suggestion != null)
            Wrap(
              spacing: 8,
              children: _suggestion!.tags
                .map((tag) => Chip(label: Text('#$tag')))
                .toList(),
            ),
          ElevatedButton(
            onPressed: _suggestTags,
            child: const Text('Suggest Tags'),
          ),
        ],
      ),
    );
  }
}

Gotchas

The old `ai-suggest-tags` EF was actually an SVG generator

There was a dedicated EF named ai-suggest-tags but its actual implementation was a quote SVG generator — a naming mismatch. It was removed during EF cap cleanup.

The fix: call ai-hub:provider.chat directly. No new EF needed, no cap slot consumed.

Groq sometimes wraps JSON in code fences

String cleanJson(String raw) => raw
  .replaceAll(RegExp(r'```

json\s*'), '')
  .replaceAll(RegExp(r'

```\s*'), '')
  .trim();

Results

Metric	Value
Implementation effort	1 new method in AIService
New EFs created	0 (reuses ai-hub)
Response time	~100ms (Groq)
Cost	Free tier

The hub pattern lets you add AI features without consuming EF cap slots. ai-hub:provider.chat becomes a universal AI gateway.

Building in public: https://my-web-app-b67f4.web.app/

Flutter #Groq #AI #buildinpublic #EdgeFunctions

Running 3 Parallel Claude Code Instances to Get $200 of Dev Work for $20/month

kanta13jp1 — Sun, 19 Apr 2026 09:54:00 +0000

Running 3 Parallel Claude Code Instances to Get $200 of Dev Work for $20/month

Overview

I build Jibun Kabushiki Kaisha — a 200-page Flutter Web SaaS — using Claude Code. On a $20/month plan, I run 3 specialized Claude Code instances in parallel to achieve roughly 10x the development throughput.

The Role Assignment System

Each instance has a fixed responsibility:

Instance	Dedicated Role	Why
VSCode	UI/design compliance (haiku-4.5)	Fast, cheap, visual tasks
PowerShell	CI/CD health + blog publishing	Quality-critical, pipeline focus
Windows App	AI University providers + migrations	Data-heavy, structured work

Why Specialization Works

Problem: Concurrent Pushes Cancel Deploys

Without coordination, all 3 instances push simultaneously:

PS push → deploy starts
VSCode push (5s later) → deploy CANCELLED → restart
Win push (3s later) → deploy CANCELLED → restart
→ 20+ minutes later: finally 1 successful deploy

This "deploy thrashing" wastes CI minutes and breaks each other's work.

Solution: Cross-Instance PR Files

Instead of direct communication, instances leave work requests in docs/cross-instance-prs/:

# docs/cross-instance-prs/20260419_trailing_comma_fix.md

## Target: PowerShell instance
## Task: Fix require_trailing_commas 36 errors
## Reason: PS instance owns CI/CD health (Rule17)

VSCode finds a lint issue → records it in cross-instance-pr → PS instance picks it up next session.

Detecting Parallel Conflicts

# Check at session start
git log origin/main --oneline -10

# Look for interleaved commits from multiple instances:
# 88e37a2 Merge (conflict resolution)
# f2520c6 (PS#136) 
# c66830d (VSCode#104)
# badccf5 (PS#135)
# → Multiple instances active → watch for ROADMAP merge conflicts

Token Conservation Strategy

On $20/month across 3 instances, every token matters.

1. CAVEMAN Communication Mode

A custom Claude Code plugin that compresses responses ~75%:

❌ Standard:
"I'll be happy to analyze the current CI failures and provide 
a comprehensive fix. Let me first examine..."

✅ CAVEMAN mode:
"2276 lint errors. dart fix --apply → format → 0 errors. push."

2. Offload Heavy Research to NotebookLM

Task	Claude cost	After NotebookLM
Read 3+ files simultaneously	~150K tokens	~5K tokens
Analyze a URL	~60K tokens	~2K tokens
Competitor research	~80K tokens	~3K tokens

3. Role Boundaries Reduce Context Loading

Each instance only loads context relevant to its specialty. The VSCode instance doesn't need to know migration history. The PS instance doesn't need design system knowledge.

A Typical Day

09:00 JST - PS: CI health check + blog dispatch
11:00 JST - VSCode: UI improvements + design token compliance  
14:00 JST - Win: Add AI University providers
16:00 JST - PS: Confirm deploy + write more blog posts
18:00 JST - Win: Migrations + EF cleanup

At each session start: git log origin/main -5 to see what other instances committed.

Results

Throughput: 3 parallel workstreams from 1 person
Cost: ~$20/month for ~$200 equivalent work
Quality: Each domain improves independently without cross-contamination

The Key Insight

The $20/month constraint doesn't limit what you can build — it forces you to think about where each token should go. Specialization turns a limitation into a feature: each instance is expert at its domain precisely because it never gets distracted by others.

Building in public: https://my-web-app-b67f4.web.app/

ClaudeCode #buildinpublic #AI #productivity

How I Applied Design Tokens Across 200 Flutter Pages in One Commit

kanta13jp1 — Sun, 19 Apr 2026 09:52:46 +0000

How I Applied Design Tokens Across 200 Flutter Pages in One Commit

The Problem

My solo SaaS project Jibun Kabushiki Kaisha has ~200 Flutter Web pages. Over time, color usage became inconsistent:

// Page A
color: Colors.grey,

// Page B  
color: Color(0xFF9E9E9E),

// Page C
color: Colors.grey[600],

The design system (docs/DESIGN.md) mandates Color(0xFFB0B0B0) for grey. Manual fixes across 200 pages aren't feasible. Here's how I automated it.

Solution: grep + Python batch replace + flutter analyze

Step 1: Find all violations

grep -rn "Colors\.grey\b" lib/ --include="*.dart" | wc -l
# → 312 occurrences across 73 files

Step 2: Python batch replace (safer than sed)

import os, re

target_dir = "lib/"
replacements = [
    (r'\bColors\.grey\b(?!\[)', 'const Color(0xFFB0B0B0)'),
    (r'\bColors\.grey\[700\]', 'const Color(0xFF616161)'),
    (r'\bColors\.grey\[600\]', 'const Color(0xFF757575)'),
    (r'\bColors\.grey\[400\]', 'const Color(0xFFBDBDBD)'),
    (r'\bColors\.grey\[200\]', 'const Color(0xFFEEEEEE)'),
]

for root, dirs, files in os.walk(target_dir):
    for file in files:
        if not file.endswith('.dart'): continue
        path = os.path.join(root, file)
        content = open(path, 'r', encoding='utf-8').read()
        new_content = content
        for pattern, replacement in replacements:
            new_content = re.sub(pattern, replacement, new_content)
        if new_content != content:
            open(path, 'w', encoding='utf-8').write(new_content)
            print(f"Updated: {path}")

Step 3: Format and validate

dart format lib/ --set-exit-if-changed
flutter analyze lib/
# → No issues found!

Step 4: Commit

git add lib/
git commit -m "style: design token batch replace — Colors.grey→Color(0xFFB0B0B0) 43 pages"

The Gotcha: Partial Name Matches

Colors.white12 and Colors.white38 are valid Flutter constants. A naive \bColors\.white\b pattern breaks them:

# ❌ This matches "white" inside "white12"
r'\bColors\.white\b'

# ✅ Negative lookahead excludes digit suffixes
r'\bColors\.white\b(?!\d)'

We learned this the hard way — 13 files had Colors.white12 → Color(0x1FFFFFFF) wrongly substituted, causing 13 CI failures that needed manual fixes.

Results

Metric	Before	After
Design token compliance	~65%	~95%
Hardcoded colors	312	12
CI lint errors	0	0
Pages fixed	-	43 in 1 commit

Key Lessons

Always end with flutter analyze 0 errors — the linter will revert partial fixes on next run
Use strict regex boundaries — partial matches cause cascading fix commits
dart format is mandatory — CI's Check formatting step will catch any missed formatting

The batch approach turns what would be a week of manual work into a 10-minute script. The only investment is getting the regex right the first time.

Building in public: https://my-web-app-b67f4.web.app/

FlutterWeb #Dart #buildinpublic #designsystem

Flutter CI Broke With 2288 Errors — How dart fix --apply Saved Us

kanta13jp1 — Sun, 19 Apr 2026 09:52:33 +0000

Flutter CI Broke With 2288 Errors — How `dart fix --apply` Saved Us

What Happened

One morning, deploy-prod.yml started failing:

error • Use 'const' with the constructor to improve performance
lib/pages/landing_page.dart:12:15 • prefer_const_constructors
... (2287 more errors)

2,288 errors. A 200-page Flutter Web app went from green to red overnight.

The cause: one line in analysis_options.yaml.

# Before:
prefer_const_constructors: warning

# The commit that broke everything:
prefer_const_constructors: error

One severity upgrade. 2,288 CI failures.

The Fix

Step 1: Immediate rollback — warning not error

# analysis_options.yaml
linter:
  rules:
    prefer_const_constructors: warning  # downgrade back

This unblocks CI, but 2,288 warnings remain as a time bomb. Anyone upgrading to error again will re-trigger the same failure. We needed a real fix.

Step 2: Batch-fix with dart fix --apply

dart fix --apply lib/

Output:

pages/landing_page.dart
  prefer_const_constructors - 47 fixes
pages/home_page.dart
  prefer_const_constructors - 89 fixes
...
2276 fixes made in 181 files.

181 files. 2,276 automatic fixes. One command.

Step 3: dart format (mandatory)

dart format lib/ --set-exit-if-changed

dart fix inserts const keywords that can change line lengths and break formatting. CI's Check formatting step will fail if you skip this.

Step 4: Verify with flutter analyze

flutter analyze lib/
# → No issues found! (ran in 23.9s)

Step 5: Commit and push

git add lib/ analysis_options.yaml
git commit -m "fix: prefer_const → warning + dart fix 2276 fixes in 181 files"
git push origin main

Bonus: require_trailing_commas Was Also Broken

The same CI run had 36 require_trailing_commas errors too. Same fix:

dart fix --apply lib/
# → require_trailing_commas - 36 fixes in 12 files

One command handles multiple lint rules simultaneously.

Gotcha #1: dart fix Can Break Things Too

dart fix --apply isn't always safe:

// ❌ What dart fix incorrectly generated:
color: const Color(0xFF9E9E9E)[400]  // Color has no [] operator

// ✅ Correct:
color: const Color(0xFFBDBDBD)  // use the actual hex value

This happened because an older dart fix run had transformed Colors.grey[400] → Color(0xFFB0B0B0)[400] — partially correct but leaving a [] subscript that Color doesn't support. Always verify with flutter analyze after running dart fix.

Gotcha #2: PdfColor Got Mangled

The pdf package uses PdfColor, not Flutter's Color. The substitution produced invalid syntax:

// ❌ dart fix's broken output:
color: PdfColor(0xFFB0B0B0)700,  // completely invalid

// ✅ Correct PdfColors API:
color: PdfColors.grey700,

PdfColor and Color have different APIs. Use PdfColors.grey700, PdfColors.grey300 etc. for the pdf package.

Summary

Step	Command	Effect
Emergency stop	Edit `analysis_options.yaml`	CI unblocked immediately
Batch fix	`dart fix --apply lib/`	Thousands of fixes in one shot
Format	`dart format lib/`	Passes `Check formatting` in CI
Verify	`flutter analyze lib/`	Confirm 0 errors

The rule: always run dart fix --apply before upgrading a lint rule to error. Upgrading severity and fixing violations in the same commit is the recipe for CI carnage.

Building in public: https://my-web-app-b67f4.web.app/

FlutterWeb #Dart #CI/CD #buildinpublic #devops

DEV Community: kanta13jp1

Pushing from git worktree branches to main — Multi-Instance Conflict Recovery Guide

Pushing from git worktree branches to main

TL;DR

Setup: Worktree Layout

3 Push Patterns

Pattern 1: HEAD:main (recommended)

Pattern 2: Explicit branch name

Pattern 3: Push from outside the worktree

Conflict Recovery

Common Conflict Patterns and Fixes

Simultaneous ROADMAP.md appends

Migration file timestamp collision

wip branch far behind main

Summary

ClaudeCode #git #buildinpublic

Running 10 Claude Code Instances in Parallel — git worktree Isolation Design

Running 10 Claude Code Instances in Parallel

The Problem: git stash Destroys Other Instances' Work

The Fix: Dedicated Worktree per Instance

10-Instance Role Assignment

Setup Script

Pushing to main

Registering Worktrees in .git/info/exclude

Results

Key Rules

Conclusion

ClaudeCode #git #buildinpublic

GitHub Actions Concurrency Trap — cancel-in-progress: false Still Drops Queued Runs

GitHub Actions Concurrency Trap

TL;DR

The Problem: 6 Deploys Cancelled in a Row

How GitHub Actions Concurrency Actually Works

The Mechanics

What Happened in Our Case

Is This a Problem?

Solutions

Option 1: Keep as-is (fine when final state is what matters)

Option 2: Unique group per commit

Option 3: Filter out noisy triggers

Summary

GitHubActions #CICD #buildinpublic

Complete Error Handling Patterns for Supabase Edge Functions — 4-Stage Fallback Design

Complete Error Handling Patterns for Supabase Edge Functions

Why Error Handling Matters

The 4-Stage Fallback Template

Input Validation

Unified Error Response Format

Supabase Client Errors

External API Calls with Timeout

Keeping deno lint at Zero Errors

Summary

Supabase #Deno #TypeScript #buildinpublic #webdev

Building an MS Project-Style Gantt Chart in Flutter Web — CustomPaint with Synchronized Scrolling

Building an MS Project-Style Gantt Chart in Flutter Web

The Goal

Architecture

Implementation

Synchronized Scrolling

Drawing Gantt Bars with CustomPaint

WbsTask Model

Supabase Schema

Gotchas

shouldRepaint performance

Alignment between header and bars

Conclusion

Flutter #CustomPaint #buildinpublic #WBS

Complete Error Handling Patterns for Supabase Edge Functions — 4-Stage Fallback Design

Complete Error Handling Patterns for Supabase Edge Functions

Why Error Handling Matters

The 4-Stage Fallback Template

Input Validation

Unified Error Response Format

Supabase Client Errors

External API Calls with Timeout

Keeping deno lint at Zero Errors

Summary

Supabase #Deno #TypeScript #buildinpublic #webdev

Building an MS Project-Style Gantt Chart in Flutter Web — CustomPaint with Synchronized Scrolling

Building an MS Project-Style Gantt Chart in Flutter Web

Pattern 1: `HEAD:main` (recommended)

The old `ai-suggest-tags` EF was actually an SVG generator

Flutter CI Broke With 2288 Errors — How `dart fix --apply` Saved Us