Skip to content

feat(planning): enforce durable task completion chronology - #266

Draft
seonghobae wants to merge 17 commits into
mainfrom
feat/planning-task-completion-chronology-v1
Draft

feat(planning): enforce durable task completion chronology#266
seonghobae wants to merge 17 commits into
mainfrom
feat/planning-task-completion-chronology-v1

Conversation

@seonghobae

@seonghobae seonghobae commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Advances #263 with the first Planning-owned temporal foundation needed before Weekly Review can expose authoritative task-completion evidence. Protected main@193a87ef54c3fe6dcda4755bce4d6bc81e3a0297 persisted planning.tasks.completed_at, but did not bind it to status and created_at; rows could therefore claim incoherent durable completion state.

Durable boundary

  • 0005_task_completion_chronology.sql adds tasks_completion_state_check as NOT VALID, so new/changed rows must already satisfy todo ⇒ completed_at IS NULL and done ⇒ completed_at >= created_at without forcing the initial historical scan during constraint addition.
  • 0006_validate_task_completion_chronology.sql validates the staged constraint as a separate deployment boundary and fails closed on historical violations.
  • Planning remains the sole owner of this schema and chronology truth. This PR does not invent overdue, stalled, or inactive, copy mutable sibling source, or move Review semantics into Planning persistence.

RED → repair evidence

The staged-migration regression first proved the direct-add implementation was wrong: exact canary 34497919705 / job 102941002188 produced the intended RED. After splitting staged addition and validation, exact canary 34498191009 / job 102941944243 passed the focused real-PostgreSQL contract and the temporary canary retired.

A fresh current-head review then found that three existing PostgreSQL integration fixtures still stopped before the new migration pair, so they were testing a schema different from deployed Planning. Bounded repair input 9ab372ec773d6e63df52305585e2f356986ec8fa, run 34561569759 / job 103145425778, proved the defect against real PostgreSQL first: postgres-planning-repository.integration.test.ts, postgres-data-rights.integration.test.ts, and postgres-today-lock-order.integration.test.ts all produced tasks_completion_state_check=missing. The repair advanced their explicit migration lists through 0005/0006; the three PostgreSQL files then passed 9/9, Planning typecheck and build passed, exact remote-head equality was checked, and the bounded repair workflow removed itself before publication.

Exact current state

Current exact head is b327e0142e3c1806d447b4b8e3491f8dacd376a0; the temporary migration-fixture repair workflow is absent. CodeRabbit independently inspected this exact head after the repair and reported no new Planning-local defect: all three explicit PostgreSQL fixtures apply 0001 through 0006 in lexical order, the NOT VALIDVALIDATE CONSTRAINT boundary remains intact, contradictory states are rejected with SQLSTATE 23514, and the validated constraint/documentation match the intended deployment semantics.

That independent review did not create a GitHub APPROVED review because this repository's CodeRabbit command configuration has explicit approval actions disabled. GitHub therefore still reports review authority as required; this PR remains Draft and is not merge-eligible. Hosted bounded RED→GREEN and a clean independent review are not being represented as repository-wide required-check GREEN or formal approval.

This PR remains the base of #267#268#269. Keep Draft until applicable exact-head repository/security gates and an actual independent approval exist. No self-approval, bypass merge, force push, destructive rebase, gate weakening, cross-service SQL, or mutable sibling-source adoption.

@coderabbitai

coderabbitai Bot commented Sep 10, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

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.

Copy link
Copy Markdown
Contributor Author

@coderabbitai review

Please review the current exact head 1de871ea86fef454639708f1044c40246ca1e9f4, especially the staged PostgreSQL NOT VALID → separate VALIDATE CONSTRAINT migration boundary, fixed-schema database regression, deployment/rollback documentation, and whether this slice accidentally claims semantics beyond durable completion chronology.

@coderabbitai

coderabbitai Bot commented Sep 10, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '== Checked-out commit =='
git rev-parse HEAD
git status --short
printf '%s\n' '== PR metadata =='
gh pr view 266 --repo ContextualWisdomLab/life-os --json headRefOid,baseRefOid,changedFiles,files,reviews,comments --jq '{headRefOid,baseRefOid,changedFiles,files:[.files[].path],reviews:[.reviews[]|{author:.author.login,state,body}],comments:[.comments[]|{author:.author.login,body}]}'
printf '%s\n' '== Merge-base and changed paths =='
base="$(git merge-base HEAD origin/main)"
printf 'merge-base=%s\n' "$base"
git diff --name-status "$base"...HEAD
printf '%s\n' '== Candidate migration and test files =='
fd -t f . apps/planning-service | rg '(migrations/(README|000[0-9].*\.sql)$|migration|database|db|test)'
printf '%s\n' '== Planning service structure =='
ast-grep outline apps/planning-service --items all --type function,class,interface --json=stream 2>/dev/null | head -c 30000 || true

Length of output: 36732


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '== Changed files with line numbers =='
for file in \
  apps/planning-service/migrations/0005_task_completion_chronology.sql \
  apps/planning-service/migrations/0006_validate_task_completion_chronology.sql \
  apps/planning-service/migrations/README.md \
  apps/planning-service/src/task-completion-chronology-migration.test.ts
do
  printf '\n--- %s ---\n' "$file"
  cat -n "$file"
done

printf '%s\n' '== Original Planning task schema =='
cat -n apps/planning-service/migrations/0001_initial_planning.sql
printf '%s\n' '== All Planning migration references and runner candidates =='
rg -n -C 4 --glob '*.ts' --glob '*.sql' \
  '(readdir|migrations/|readFile.*migration|apply.*[Mm]igration|CREATE TABLE.*tasks|ALTER TABLE.*tasks|completed_at|status)' \
  apps/planning-service
printf '%s\n' '== Identity staged-validation precedent =='
rg -n -i -C 5 --glob '*.sql' --glob '*.md' \
  'NOT VALID|VALIDATE CONSTRAINT' apps
printf '%s\n' '== Exact PR diff =='
git diff --check 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD
git diff --find-renames --unified=80 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD -- apps/planning-service

Length of output: 128789


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '== Planning package and test configuration =='
fd -t f -a 'package.json|vitest.*|vite.config.*|tsconfig.*' . \
  -E node_modules -E dist -E build \
  | while IFS= read -r file; do
      case "$file" in
        *planning-service*|./package.json|package.json)
          printf '\n--- %s ---\n' "$file"
          cat -n "$file"
          ;;
      esac
    done

printf '%s\n' '== Full explicit Planning migration lists =='
for file in \
  apps/planning-service/src/postgres-planning-repository.integration.test.ts \
  apps/planning-service/tests/postgres-data-rights.integration.test.ts \
  apps/planning-service/tests/postgres-today-lock-order.integration.test.ts
do
  printf '\n--- %s ---\n' "$file"
  sed -n '/async function apply.*Migrations/,/^}/p' "$file"
done

printf '%s\n' '== Test discovery references =='
rg -n -C 3 --glob 'package.json' --glob '*.json' --glob '*.ts' \
  '(task-completion-chronology-migration|vitest|test:.*planning|PLANNING_DATABASE_URL)' \
  . -g '!node_modules/**' -g '!dist/**' -g '!build/**'

printf '%s\n' '== PR checks and workflow changes =='
gh pr view 266 --repo ContextualWisdomLab/life-os --json statusCheckRollup --jq \
  '.statusCheckRollup[] | {name, status, conclusion, detailsUrl}'
git diff --name-status 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD -- .github
printf '%s\n' '== Commit history for the focused migration test =='
git log --format='%H %s' --reverse 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297..HEAD -- apps/planning-service/src/task-completion-chronology-migration.test.ts

Length of output: 148175


🏁 Script executed:

#!/bin/bash
set -euo pipefail

for job in 102942895955 102943286521 102942958995; do
  printf '\n== Job %s ==\n' "$job"
  gh run view "$job" --repo ContextualWisdomLab/life-os --log-failed 2>&1 | tail -n 100
done

Length of output: 695


@seonghobae I reviewed exact head 1de871ea86fef454639708f1044c40246ca1e9f4.

Finding

  • Medium — Existing PostgreSQL integration fixtures do not apply the current migration chain.
    apps/planning-service/src/postgres-planning-repository.integration.test.ts omits both 0005 and 0006 from its explicit migration list. apps/planning-service/tests/postgres-data-rights.integration.test.ts and apps/planning-service/tests/postgres-today-lock-order.integration.test.ts also omit them. These fixtures therefore test a schema that differs from the deployed schema documented in apps/planning-service/migrations/README.md. Add 0005_task_completion_chronology.sql and 0006_validate_task_completion_chronology.sql to every explicit list, or use one lexical migration-discovery helper.

Verified

  • 0005_task_completion_chronology.sql adds tasks_completion_state_check with NOT VALID.
  • 0006_validate_task_completion_chronology.sql validates that same constraint in a separate migration.
  • The constraint permits only the two required durable states.
  • The fixed-schema PostgreSQL regression uses parameterized values. It rejects all three contradictory new-row states and verifies convalidated = true.
  • The migration README describes the staged validation boundary, fail-closed deployment behavior, service-owned database configuration, and operator rollback semantics.
  • This slice does not define overdue, stalled, inactive, audit-history, browser-authority, or Weekly Review semantics.

GitHub check logs could not be retrieved because the referenced job IDs returned HTTP 404. I could not independently classify the current failed and in-progress checks.

You are interacting with an AI system.

Copy link
Copy Markdown
Contributor Author

Exact-head gate sweep for 1de871ea86fef454639708f1044c40246ca1e9f4:

  • Planning chronology delta remains bounded to migrations 0005/0006, migration docs, and the focused PostgreSQL contract. All current inline review threads are resolved; there is still no independent current-head APPROVED review.
  • CI run 34498472573: compose_runtime, today-concurrency, browser-acceptance, and merge_compatibility are GREEN. validate fails before source tests at root pnpm format:check because protected ancestry's .github/workflows/appguardrail.yml is not Prettier-clean. This is the already-owned shared control-plane delta; do not copy it into this Planning leaf.
  • Security run 34498472638: exact-head Trivy execution and SARIF upload succeed, then the gate reports the same shared lockfile families already owned by fix(security): upgrade shared vulnerable dependency graph #249: multer (3), next (2), qs (2), sharp (1). No Planning-local suppression or override is warranted.
  • Commercial Readiness 34498472758: exact checkout succeeds; bounded GitHub snapshot collection fails with GitHub API response exceeded the size limit, before buyer-gap audit. Keep this with the canonical Commercial Readiness/shared-foundation owner rather than expanding response caps in Planning.
  • CodeQL 34498476661: current-head dispatch succeeds, but all three compatibility shards remain fail-closed because the authenticated terminal verdict is still pending; the jobs explicitly expect the dispatch path to publish the verdict and rerun the exact shard.
  • SAST 34498472533 and AppGuardrail 34498472498 are exact-head GREEN.

#266 therefore stays Draft. Its local migration contract is not the cause of the remaining required-check failures, and predecessor/shared-owner evidence is not being promoted to repository-wide GREEN. Next Planning work is kept dependency-ordered: explicit server-owned task completion transition first, then the bounded Weekly Review projection required by #263.

Copy link
Copy Markdown
Contributor Author

@coderabbitai review

Please review the current exact head 1de871ea86fef454639708f1044c40246ca1e9f4, with particular attention to the staged NOT VALIDVALIDATE CONSTRAINT migration boundary, rollback semantics, and whether the Planning-owned chronology invariant is sufficiently covered by real PostgreSQL evidence. This is a request for independent review; do not treat prior COMMENT submissions as approval.

@coderabbitai

coderabbitai Bot commented Sep 11, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

expected='1de871ea86fef454639708f1044c40246ca1e9f4'
actual="$(git rev-parse HEAD)"
printf 'HEAD=%s\nexpected=%s\n' "$actual" "$expected"
git status --short
if [ "$actual" != "$expected" ]; then
  printf '%s\n' 'ERROR: checkout is not the requested exact head.' >&2
  exit 2
fi

printf '\n== Exact change set ==\n'
git diff --check 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD
git diff --name-status 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD

printf '\n== Migration and focused test maps ==\n'
ast-grep outline apps/planning-service/migrations/0005_task_completion_chronology.sql --items all 2>/dev/null || true
ast-grep outline apps/planning-service/migrations/0006_validate_task_completion_chronology.sql --items all 2>/dev/null || true
ast-grep outline apps/planning-service/src/task-completion-chronology-migration.test.ts --items all --type function 2>/dev/null || true

printf '\n== Changed migration, documentation, and contract test ==\n'
for file in \
  apps/planning-service/migrations/0005_task_completion_chronology.sql \
  apps/planning-service/migrations/0006_validate_task_completion_chronology.sql \
  apps/planning-service/migrations/README.md \
  apps/planning-service/src/task-completion-chronology-migration.test.ts \
  apps/planning-service/migrations/0001_initial_planning.sql
do
  printf '\n--- %s ---\n' "$file"
  cat -n "$file"
done

printf '\n== All explicit Planning migration application sites ==\n'
rg -n -C 12 --glob '*.ts' \
  '(000[0-9]_[A-Za-z0-9_-]+\.sql|apply[A-Za-z]*Migrations|readFile.*migrations|migrations/000)' \
  apps/planning-service

printf '\n== Migration runner / ordering references ==\n'
rg -n -C 5 --glob '*.ts' --glob '*.md' --glob '*.sql' \
  '(readdir|sort\(|migration.*order|migration.*list|VALIDATE CONSTRAINT|NOT VALID|DROP CONSTRAINT|rollback|completed_at)' \
  apps/planning-service

printf '\n== PR reviews and current checks ==\n'
gh pr view 266 --repo ContextualWisdomLab/life-os \
  --json headRefOid,isDraft,reviews,statusCheckRollup \
  --jq '{headRefOid,isDraft,reviews:[.reviews[]|{author:.author.login,state,commit:.commit.oid}],checks:[.statusCheckRollup[]|{name,status,conclusion}]}'

Length of output: 60116


@seonghobae I reviewed exact head 1de871ea86fef454639708f1044c40246ca1e9f4. I did not treat prior COMMENTED reviews as approval.

Finding

  • Medium — Existing PostgreSQL integration fixtures do not apply the deployed migration chain.
    apps/planning-service/src/postgres-planning-repository.integration.test.ts applies only 00010003. apps/planning-service/tests/postgres-data-rights.integration.test.ts applies only 00010004. apps/planning-service/tests/postgres-today-lock-order.integration.test.ts applies only 00010003. These fixtures run against schemas that lack tasks_completion_state_check. Add 0005_task_completion_chronology.sql and 0006_validate_task_completion_chronology.sql to each explicit list, or replace the lists with one ordered Planning migration helper.

Verified

  • 0005_task_completion_chronology.sql adds tasks_completion_state_check with NOT VALID.
  • 0006_validate_task_completion_chronology.sql validates that exact constraint in a separate migration.
  • The constraint allows only:
    • todo with completed_at IS NULL
    • done with non-null completed_at >= created_at
  • The focused contract uses PostgreSQL through pg when PLANNING_DATABASE_URL is set.
  • The contract accepts both valid states.
  • The contract rejects all three contradictory new-row states with PostgreSQL error 23514.
  • The contract verifies pg_constraint.convalidated = true after 0006.
  • The rollback documentation correctly describes 0006 as creating no separate object. It requires explicit operator approval before dropping the single constraint.
  • The migration and documentation do not add overdue, stalled, inactive, audit-history, browser-authority, or Weekly Review semantics.

The focused database test is conditional on PLANNING_DATABASE_URL. The source establishes real PostgreSQL coverage when that variable is present. Source inspection alone cannot prove that the current required checks executed that test.

You are interacting with an AI system.

Copy link
Copy Markdown
Contributor Author

@coderabbitai review

Current exact head is now b327e0142e3c1806d447b4b8e3491f8dacd376a0. The prior valid finding about PostgreSQL integration fixtures stopping before 0005/0006 has been repaired through a hosted real-PostgreSQL RED→GREEN run (34561569759 / 103145425778): all three stale fixtures first proved tasks_completion_state_check=missing, then the explicit migration lists were advanced through the current staged/validated chronology boundary; the three PostgreSQL files passed 9/9, Planning typecheck and build passed, exact remote-head equality was checked, and the bounded repair workflow retired itself before publication. Please independently review this new exact head; COMMENTED evidence is not approval.

@coderabbitai

coderabbitai Bot commented Sep 11, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

expected='b327e0142e3c1806d447b4b8e3491f8dacd376a0'
actual="$(git rev-parse HEAD)"
printf '== Exact checkout ==\nHEAD=%s\nexpected=%s\n' "$actual" "$expected"
git status --short
if [ "$actual" != "$expected" ]; then
  printf '%s\n' 'ERROR: checkout does not match the requested exact head.' >&2
  exit 2
fi

printf '\n== PR remote state ==\n'
gh pr view 266 --repo ContextualWisdomLab/life-os \
  --json headRefOid,baseRefOid,isDraft,reviews,statusCheckRollup \
  --jq '{headRefOid,baseRefOid,isDraft,reviews:[.reviews[]|{author:.author.login,state,commit:.commit.oid}],checks:[.statusCheckRollup[]|{name,status,conclusion,detailsUrl}]}'

printf '\n== Change set from protected base ==\n'
git diff --check 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD
git diff --name-status 193a87ef54c3fe6dcda4755bce4d6bc81e3a0297...HEAD
printf '\n== New-head repair diff ==\n'
git diff --check 1de871ea86fef454639708f1044c40246ca1e9f4...HEAD
git diff --find-renames --unified=100 1de871ea86fef454639708f1044c40246ca1e9f4...HEAD -- apps/planning-service

printf '\n== Relevant migration and test structure ==\n'
ast-grep outline apps/planning-service/src/postgres-planning-repository.integration.test.ts --items all --type function 2>/dev/null || true
ast-grep outline apps/planning-service/tests/postgres-data-rights.integration.test.ts --items all --type function 2>/dev/null || true
ast-grep outline apps/planning-service/tests/postgres-today-lock-order.integration.test.ts --items all --type function 2>/dev/null || true
ast-grep outline apps/planning-service/src/task-completion-chronology-migration.test.ts --items all --type function 2>/dev/null || true

printf '\n== All Planning migration application references ==\n'
rg -n -C 10 --glob '*.ts' \
  '(000[0-9]_[A-Za-z0-9_-]+\.sql|apply[A-Za-z]*Migrations|migrations/000)' \
  apps/planning-service

printf '\n== Migrations, documentation, and affected PostgreSQL tests ==\n'
for file in \
  apps/planning-service/migrations/0001_initial_planning.sql \
  apps/planning-service/migrations/0005_task_completion_chronology.sql \
  apps/planning-service/migrations/0006_validate_task_completion_chronology.sql \
  apps/planning-service/migrations/README.md \
  apps/planning-service/src/task-completion-chronology-migration.test.ts \
  apps/planning-service/src/postgres-planning-repository.integration.test.ts \
  apps/planning-service/tests/postgres-data-rights.integration.test.ts \
  apps/planning-service/tests/postgres-today-lock-order.integration.test.ts
do
  printf '\n--- %s ---\n' "$file"
  cat -n "$file"
done

printf '\n== Hosted repair workflow and run evidence ==\n'
gh run view 34561569759 --repo ContextualWisdomLab/life-os \
  --json databaseId,headSha,status,conclusion,event,workflowName,jobs \
  --jq '{databaseId,headSha,status,conclusion,event,workflowName,jobs:[.jobs[]|{databaseId,name,status,conclusion,startedAt,completedAt}]}'
gh run view 34561569759 --repo ContextualWisdomLab/life-os --log-failed 2>&1 | tail -n 250

Length of output: 84465


@seonghobae I independently reviewed exact head b327e0142e3c1806d447b4b8e3491f8dacd376a0.

I found no new Planning-local defect.

The prior migration-chain finding is repaired. These fixtures now apply 0001 through 0006 in lexical order:

  • apps/planning-service/src/postgres-planning-repository.integration.test.ts
  • apps/planning-service/tests/postgres-data-rights.integration.test.ts
  • apps/planning-service/tests/postgres-today-lock-order.integration.test.ts

The migration boundary remains correct:

  • 0005_task_completion_chronology.sql adds tasks_completion_state_check with NOT VALID.
  • 0006_validate_task_completion_chronology.sql validates the same constraint in a separate migration.
  • The focused PostgreSQL contract accepts the two coherent states.
  • It rejects each contradictory new state with SQLSTATE 23514.
  • It verifies pg_constraint.convalidated = true after validation.

The rollback documentation remains consistent. It identifies 0006 as creating no separate object and requires explicit operator approval before removal of the durable constraint.

This slice does not add overdue, stalled, inactive, audit-history, browser-authority, or Weekly Review semantics.

Hosted run 34561569759 succeeded. Its recorded SHA is 9ab372ec773d6e63df52305585e2f356986ec8fa, not the current exact head. Therefore, it supports the repair evidence but does not establish terminal exact-head check evidence by itself. The PR is still Draft, no independent APPROVED review exists, and CodeQL JavaScript/TypeScript analysis was still in progress during inspection.


If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

You are interacting with an AI system.

Copy link
Copy Markdown
Contributor Author

Current exact head remains b327e0142e3c1806d447b4b8e3491f8dacd376a0. The latest bounded repair only advanced existing Planning PostgreSQL integration fixtures through migrations 0005/0006 after proving the missing-constraint RED, then passed the three real-PostgreSQL files 9/9 plus Planning typecheck/build. Please review this exact current diff and approval authority without transferring predecessor review state.

@coderabbitai approve

@coderabbitai

coderabbitai Bot commented Sep 11, 2026

Copy link
Copy Markdown
🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

repo="ContextualWisdomLab/life-os"
expected="b327e0142e3c1806d447b4b8e3491f8dacd376a0"
actual="$(git rev-parse HEAD)"
printf '== Exact checkout ==\nHEAD=%s\nexpected=%s\n' "$actual" "$expected"
git status --short
if [ "$actual" != "$expected" ]; then
  echo "ERROR: local checkout does not match requested head" >&2
  exit 2
fi

printf '\n== Pull request authority and current check state ==\n'
gh pr view 266 --repo "$repo" \
  --json headRefOid,baseRefOid,isDraft,reviewDecision,reviews,statusCheckRollup \
  --jq '{
    headRefOid, baseRefOid, isDraft, reviewDecision,
    reviews: [.reviews[] | {author: .author.login, state, commit: .commit.oid}],
    checks: [.statusCheckRollup[] | {name, status, conclusion, detailsUrl}]
  }'

printf '\n== Current change set from protected base ==\n'
base="193a87ef54c3fe6dcda4755bce4d6bc81e3a0297"
git diff --check "$base"...HEAD
git diff --name-status "$base"...HEAD

printf '\n== Repair diff at requested head ==\n'
git diff --check 1de871ea86fef454639708f1044c40246ca1e9f4...HEAD
git diff --unified=40 1de871ea86fef454639708f1044c40246ca1e9f4...HEAD -- \
  apps/planning-service/src/postgres-planning-repository.integration.test.ts \
  apps/planning-service/tests/postgres-data-rights.integration.test.ts \
  apps/planning-service/tests/postgres-today-lock-order.integration.test.ts

printf '\n== Migration boundary and all explicit Planning migration lists ==\n'
for file in \
  apps/planning-service/migrations/0001_initial_planning.sql \
  apps/planning-service/migrations/0005_task_completion_chronology.sql \
  apps/planning-service/migrations/0006_validate_task_completion_chronology.sql \
  apps/planning-service/migrations/README.md \
  apps/planning-service/src/task-completion-chronology-migration.test.ts \
  apps/planning-service/src/postgres-planning-repository.integration.test.ts \
  apps/planning-service/tests/postgres-data-rights.integration.test.ts \
  apps/planning-service/tests/postgres-today-lock-order.integration.test.ts
do
  printf '\n--- %s ---\n' "$file"
  cat -n "$file"
done

printf '\n== All explicit Planning SQL migration references ==\n'
rg -n -C 8 --glob '*.ts' \
  '(000[0-9]_[A-Za-z0-9_-]+\.sql|apply[A-Za-z]*Migrations|migrations/000)' \
  apps/planning-service

printf '\n== Claimed hosted repair run ==\n'
gh run view 34561569759 --repo "$repo" \
  --json databaseId,headSha,status,conclusion,workflowName,jobs \
  --jq '{databaseId,headSha,status,conclusion,workflowName,jobs:[.jobs[]|{databaseId,name,status,conclusion}]}' \
  || true

Length of output: 75834


@seonghobae I independently reviewed exact head b327e0142e3c1806d447b4b8e3491f8dacd376a0.

I found no Planning-local defect.

All three explicit PostgreSQL fixtures now apply migrations 0001 through 0006 in lexical order. The staged boundary remains correct:

  • 0005_task_completion_chronology.sql adds tasks_completion_state_check with NOT VALID.
  • 0006_validate_task_completion_chronology.sql validates that same constraint.
  • The focused PostgreSQL contract verifies valid states, rejects each contradictory state with SQLSTATE 23514, and verifies convalidated = true.
  • The migration documentation retains the correct forward-only and operator-approved rollback semantics.

Hosted run 34561569759 succeeded on 9ab372ec773d6e63df52305585e2f356986ec8fa. I did not use that predecessor SHA as exact-head approval evidence.

This approval applies only to b327e0142e3c1806d447b4b8e3491f8dacd376a0. The pull request remains Draft. GitHub still reports REVIEW_REQUIRED, and unnamed check entries have no terminal status. These conditions remain separate from this code-review approval.

✅ Action performed

Comments resolved. Approval is disabled; enable reviews.request_changes_workflow to allow explicit top-level @coderabbitai resolve or @coderabbitai approve commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request priority: medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants