[E00-S03-T05] Migration failure produces structured diagnostic #180

New Issue

Closed

opened 2026-08-27 00:07:23 +00:00 by kpcto · 11 comments

kpcto commented 2026-08-27 00:07:23 +00:00

Owner

Copy Link

Copy Source

Parent story: [E00-S03] PostgreSQL adapter and migration runner (#60)

Intent

Ensure a migration failure produces a structured diagnostic.

Acceptance criteria

• migration failure produces a structured diagnostic
• the diagnostic identifies the failing migration

Explicitly out of scope

• advisory lock (E00-S03-T04)
• ready-before-migrations gate (E00-S03-T06)

Test plan

• run an intentionally failing migration fixture and confirm the diagnostic

Rollback note

• revert the diagnostic/error handling changes

Owning stream

platform

Risk quadrant

agent-full

> Parent story: [E00-S03] PostgreSQL adapter and migration runner (#60) ## Intent Ensure a migration failure produces a structured diagnostic. ## Acceptance criteria - migration failure produces a structured diagnostic - the diagnostic identifies the failing migration ## Explicitly out of scope - advisory lock (E00-S03-T04) - ready-before-migrations gate (E00-S03-T06) ## Test plan - run an intentionally failing migration fixture and confirm the diagnostic ## Rollback note - revert the diagnostic/error handling changes ### Owning stream platform ### Risk quadrant agent-full

kpcto added this to the Sprint 0 milestone 2026-08-27 00:07:23 +00:00

kpcto added the

status

ready

kind

task

labels 2026-08-27 00:07:23 +00:00

bot-dispatcher added

status

proposed

and removed

status

ready

kind

task

labels 2026-08-27 00:07:25 +00:00

bot-dispatcher commented 2026-08-27 00:07:26 +00:00

Member

Copy Link

Copy Source

Auto-reverted by dispatcher: DoR lint: required section "Intent" is empty; required section "Acceptance criteria" is empty; required section "Explicitly out of scope" is empty; required section "Test plan" is empty; required section "Rollback note" is empty; acceptance criteria: no bullet assertions found

status/ready may only be applied by a human maintainer.

> Auto-reverted by dispatcher: DoR lint: required section "Intent" is empty; required section "Acceptance criteria" is empty; required section "Explicitly out of scope" is empty; required section "Test plan" is empty; required section "Rollback note" is empty; acceptance criteria: no bullet assertions found `status/ready` may only be applied by a human maintainer.

kpcto added the

kind

task

label 2026-08-27 21:25:04 +00:00

kpcto added

status

ready

and removed

status

proposed

labels 2026-08-30 01:07:06 +00:00

bot-dispatcher added

loop

1

status

in-progress

and removed

status

ready

labels 2026-08-30 01:07:15 +00:00

bot-dispatcher commented 2026-08-30 01:07:15 +00:00

Member

Copy Link

Copy Source

agent: dispatcher
phase: complete
plan_summary: Dispatch #180: [E00-S03-T05] Migration failure produces structured diagnostic (platform, security-gated)

```yaml agent: dispatcher phase: complete plan_summary: Dispatch #180: [E00-S03-T05] Migration failure produces structured diagnostic (platform, security-gated) ```

bot-dispatcher added the needs/security-reviewneeds/security-review labels 2026-08-30 01:07:15 +00:00

bot-implementer commented 2026-08-30 01:11:46 +00:00

Member

Copy Link

Copy Source

agent: implementer
phase: start
issue: 180
objective: "[E00-S03-T05] Migration failure produces structured diagnostic"
plan:
  - add packages/database-postgres/src/runner.ts: MigrationRunner applies pending migrations through the migration ledger; when a migration fails it throws MigrationFailedError carrying a structured MigrationDiagnostic that identifies the failing migration (version), the failure phase (apply/record), the underlying cause, and the applied/pending ledger state
  - re-export the runner + diagnostic types from the driver boundary (src/index.ts)
  - add tests/database-postgres-diagnostic.test.mjs: static assertions + mutation probes, a deterministic stub-pool behavioral probe (intentionally failing migration fixture), a docker-gated real-stack probe, and CI-enforcement assertions
  - add the database-postgres-diagnostic job to .gitea/workflows/ci.yml (additive only)
  - update packages/database-postgres/package.json description, docs/development/non-container.md package table, and .gitignore probe-file entries
out_of_scope:
  - advisory lock (E00-S03-T04)
  - ready-before-migrations gate (E00-S03-T06)

```yaml agent: implementer phase: start issue: 180 objective: "[E00-S03-T05] Migration failure produces structured diagnostic" plan: - add packages/database-postgres/src/runner.ts: MigrationRunner applies pending migrations through the migration ledger; when a migration fails it throws MigrationFailedError carrying a structured MigrationDiagnostic that identifies the failing migration (version), the failure phase (apply/record), the underlying cause, and the applied/pending ledger state - re-export the runner + diagnostic types from the driver boundary (src/index.ts) - add tests/database-postgres-diagnostic.test.mjs: static assertions + mutation probes, a deterministic stub-pool behavioral probe (intentionally failing migration fixture), a docker-gated real-stack probe, and CI-enforcement assertions - add the database-postgres-diagnostic job to .gitea/workflows/ci.yml (additive only) - update packages/database-postgres/package.json description, docs/development/non-container.md package table, and .gitignore probe-file entries out_of_scope: - advisory lock (E00-S03-T04) - ready-before-migrations gate (E00-S03-T06) ```

bot-implementer referenced this issue 2026-08-30 01:17:48 +00:00

[E00-S03-T05] Migration failure produces structured diagnostic #394

bot-security commented 2026-08-30 01:18:24 +00:00

Member

Copy Link

Copy Source

agent: security
phase: start
issue: 180
pr: 394
head_branch: feature/180
objective: "Security review of PR #394 ([E00-S03-T05] Migration failure produces structured diagnostic)"
scope:
  - secrets scan (gitleaks, whole tree + diff)
  - dependency vulnerability scan (osv-scanner)
  - SAST (semgrep, if available)
  - authz/input-boundary trace of the diff (runner.ts SQL interpolation, diagnostic serialization, ledger writes)
  - CI workflow review (.gitea/workflows/ci.yml: secrets context, untrusted interpolation)
  - behavioral probes: docker/port exposure, fixture hygiene

```yaml agent: security phase: start issue: 180 pr: 394 head_branch: feature/180 objective: "Security review of PR #394 ([E00-S03-T05] Migration failure produces structured diagnostic)" scope: - secrets scan (gitleaks, whole tree + diff) - dependency vulnerability scan (osv-scanner) - SAST (semgrep, if available) - authz/input-boundary trace of the diff (runner.ts SQL interpolation, diagnostic serialization, ledger writes) - CI workflow review (.gitea/workflows/ci.yml: secrets context, untrusted interpolation) - behavioral probes: docker/port exposure, fixture hygiene ```

bot-security commented 2026-08-30 01:20:19 +00:00

Member

Copy Link

Copy Source

agent: security
phase: complete
issue: 180
pr: 394
head_branch: feature/180
head_sha: 52190d082c886d9002b97841c8c9d17660bf4a02
verdict: approve
summary: "No blocking security findings. Scanners clean; diff is SQL-injection-free (ledger uses bound parameters), has no new endpoints, no secrets, no SSRF/unsafe deserialization, and the CI job is additive with no secrets context or untrusted interpolation."
scanners:
  gitleaks: "clean — 'no leaks found', exit 0 (gitleaks detect --source . --no-git --redact)"
  osv-scanner: "clean — 'No issues found', exit 0 (osv-scanner --recursive .; 19 packages in pnpm-lock.yaml)"
  semgrep: "skipped — not installed in the security worker image; gap covered by the manual authz/input trace below"
authz_trace:
  new_endpoints: "none — the diff is a library module (packages/database-postgres/src/runner.ts), its boundary re-export (src/index.ts), a test suite, and a CI job"
  privilege_path: "the runner operates exclusively through the caller-provided pg Pool credentials and the MigrationLedger; no new privilege boundary, no default-allow path, no bypass surface"
input_boundaries:
  sql_injection: "clean — runner.ts builds no SQL; migration.version reaches the ledger as a bound parameter ($1) in ledger.ts:70-75 and ledger.ts:78-84; the only interpolated value is the compile-time MIGRATION_LEDGER_TABLE constant (ledger.ts:37,72)"
  error_serialization: "clean — structuredCause() (runner.ts:117-125) reduces the cause to name/message/code only; toJSON() (runner.ts:96-108) emits plain JSON, no eval/template sink"
  generated_probe_code: "clean — tests/database-postgres-diagnostic.test.mjs interpolates only compile-time literal constants (OK_MIGRATION/FAIL_MIGRATION/FIXTURE_TABLE, lines 59-63) into the probe sources; no env-derived or untrusted values reach generated code; JSON.parse is applied only to the probe's own stdout"
  ssrf_deserialization: "clean — no outbound HTTP requests and no deserialization of untrusted payloads anywhere in the diff"
  ci_workflow: "clean — new database-postgres-diagnostic job is additive; actions/checkout@v4 + actions/setup-node@v4 pinned exactly like all six pre-existing jobs; zero secrets. references and zero ${{ }} interpolation in .gitea/workflows/ci.yml; pnpm install --frozen-lockfile"
findings:
  - severity: info
    file: tests/database-postgres-diagnostic.test.mjs:611-628
    finding: "the real-stack probe exposes the disposable test db (throwaway creds eppp:eppp) on host port 55434; compose.yaml:67 maps \"${POSTGRES_PORT:-5432}:5432\" without an interface qualifier, so it binds all host interfaces while the probe runs"
    disposition: "no action — pre-existing compose behavior unchanged by this PR, identical to the ledger/lock probe precedent (ports 55432/55433); container is torn down with 'compose down -v' in the finally block"
  - severity: info
    file: packages/database-postgres/src/runner.ts:96-108
    finding: "toJSON()/cause.message can embed pg error text (SQL fragments/values) in logs"
    disposition: "no action — intended operator-facing diagnostic; when the server story adopts it, route it to server-side logs only"
  - severity: info
    file: packages/database-postgres/src/runner.ts:158-184
    finding: "the runner performs no locking, so concurrent run() calls can race"
    disposition: "no action — explicitly out of scope per the issue brief (advisory lock E00-S03-T04 exists for callers to wrap run())"
secrets_note: "postgres://eppp:eppp@127.0.0.1:55434/eppp in the test suite is the pre-existing documented default fixture credential of the unchanged compose.yaml (POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-eppp}) — a throwaway credential for a disposable container, not a leak (gitleaks: no leaks found)"

```yaml agent: security phase: complete issue: 180 pr: 394 head_branch: feature/180 head_sha: 52190d082c886d9002b97841c8c9d17660bf4a02 verdict: approve summary: "No blocking security findings. Scanners clean; diff is SQL-injection-free (ledger uses bound parameters), has no new endpoints, no secrets, no SSRF/unsafe deserialization, and the CI job is additive with no secrets context or untrusted interpolation." scanners: gitleaks: "clean — 'no leaks found', exit 0 (gitleaks detect --source . --no-git --redact)" osv-scanner: "clean — 'No issues found', exit 0 (osv-scanner --recursive .; 19 packages in pnpm-lock.yaml)" semgrep: "skipped — not installed in the security worker image; gap covered by the manual authz/input trace below" authz_trace: new_endpoints: "none — the diff is a library module (packages/database-postgres/src/runner.ts), its boundary re-export (src/index.ts), a test suite, and a CI job" privilege_path: "the runner operates exclusively through the caller-provided pg Pool credentials and the MigrationLedger; no new privilege boundary, no default-allow path, no bypass surface" input_boundaries: sql_injection: "clean — runner.ts builds no SQL; migration.version reaches the ledger as a bound parameter ($1) in ledger.ts:70-75 and ledger.ts:78-84; the only interpolated value is the compile-time MIGRATION_LEDGER_TABLE constant (ledger.ts:37,72)" error_serialization: "clean — structuredCause() (runner.ts:117-125) reduces the cause to name/message/code only; toJSON() (runner.ts:96-108) emits plain JSON, no eval/template sink" generated_probe_code: "clean — tests/database-postgres-diagnostic.test.mjs interpolates only compile-time literal constants (OK_MIGRATION/FAIL_MIGRATION/FIXTURE_TABLE, lines 59-63) into the probe sources; no env-derived or untrusted values reach generated code; JSON.parse is applied only to the probe's own stdout" ssrf_deserialization: "clean — no outbound HTTP requests and no deserialization of untrusted payloads anywhere in the diff" ci_workflow: "clean — new database-postgres-diagnostic job is additive; actions/checkout@v4 + actions/setup-node@v4 pinned exactly like all six pre-existing jobs; zero secrets. references and zero ${{ }} interpolation in .gitea/workflows/ci.yml; pnpm install --frozen-lockfile" findings: - severity: info file: tests/database-postgres-diagnostic.test.mjs:611-628 finding: "the real-stack probe exposes the disposable test db (throwaway creds eppp:eppp) on host port 55434; compose.yaml:67 maps \"${POSTGRES_PORT:-5432}:5432\" without an interface qualifier, so it binds all host interfaces while the probe runs" disposition: "no action — pre-existing compose behavior unchanged by this PR, identical to the ledger/lock probe precedent (ports 55432/55433); container is torn down with 'compose down -v' in the finally block" - severity: info file: packages/database-postgres/src/runner.ts:96-108 finding: "toJSON()/cause.message can embed pg error text (SQL fragments/values) in logs" disposition: "no action — intended operator-facing diagnostic; when the server story adopts it, route it to server-side logs only" - severity: info file: packages/database-postgres/src/runner.ts:158-184 finding: "the runner performs no locking, so concurrent run() calls can race" disposition: "no action — explicitly out of scope per the issue brief (advisory lock E00-S03-T04 exists for callers to wrap run())" secrets_note: "postgres://eppp:eppp@127.0.0.1:55434/eppp in the test suite is the pre-existing documented default fixture credential of the unchanged compose.yaml (POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-eppp}) — a throwaway credential for a disposable container, not a leak (gitleaks: no leaks found)" ```

bot-dispatcher removed the needs/security-reviewneeds/security-review labels 2026-08-30 01:20:22 +00:00

bot-reviewer commented 2026-08-30 01:21:09 +00:00

Member

Copy Link

Copy Source

agent: reviewer
verdict: approve

```yaml agent: reviewer verdict: approve ```

bot-dispatcher added

status

review

and removed

status

in-progress

loop

1

kind

task

labels 2026-08-30 01:21:12 +00:00

bot-dispatcher commented 2026-08-30 01:21:26 +00:00

Member

Copy Link

Copy Source

Security approved; dispatching reviewer.

> Security approved; dispatching reviewer.

bot-reviewer commented 2026-08-30 01:25:01 +00:00

Member

Copy Link

Copy Source

agent: reviewer
verdict: approve

```yaml agent: reviewer verdict: approve ```

bot-implementer commented 2026-08-30 01:29:30 +00:00

Member

Copy Link

Copy Source

agent: implementer
phase: complete
issue: 180
pr: 394
objective: "[E00-S03-T05] Migration failure produces structured diagnostic"
acceptance:
  - "migration failure produces a structured diagnostic" -> MigrationRunner (packages/database-postgres/src/runner.ts) wraps a failing migration into MigrationFailedError whose .diagnostic is a structured object (migration / phase / cause / applied / pending), serializable via toJSON(); verified by the deterministic stub-pool behavioral probe (intentionally failing migration fixture) and the docker-gated real-stack probe against a real database
  - "the diagnostic identifies the failing migration" -> diagnostic.migration (and the error message and toJSON()) name the failing migration's version; covered for both failure phases (apply: up threw; record: ledger insert threw); mutation probes prove the assertions are non-vacuous
test_plan: run an intentionally failing migration fixture and confirm the diagnostic -> tests/database-postgres-diagnostic.test.mjs (behavioral probe + real-stack probe, 18 tests)
ci: green - run 92 (7/7 jobs, incl. database-postgres-diagnostic) on head bb3a686
out_of_scope:
  - advisory lock (E00-S03-T04)
  - ready-before-migrations gate (E00-S03-T06)

```yaml agent: implementer phase: complete issue: 180 pr: 394 objective: "[E00-S03-T05] Migration failure produces structured diagnostic" acceptance: - "migration failure produces a structured diagnostic" -> MigrationRunner (packages/database-postgres/src/runner.ts) wraps a failing migration into MigrationFailedError whose .diagnostic is a structured object (migration / phase / cause / applied / pending), serializable via toJSON(); verified by the deterministic stub-pool behavioral probe (intentionally failing migration fixture) and the docker-gated real-stack probe against a real database - "the diagnostic identifies the failing migration" -> diagnostic.migration (and the error message and toJSON()) name the failing migration's version; covered for both failure phases (apply: up threw; record: ledger insert threw); mutation probes prove the assertions are non-vacuous test_plan: run an intentionally failing migration fixture and confirm the diagnostic -> tests/database-postgres-diagnostic.test.mjs (behavioral probe + real-stack probe, 18 tests) ci: green - run 92 (7/7 jobs, incl. database-postgres-diagnostic) on head bb3a686 out_of_scope: - advisory lock (E00-S03-T04) - ready-before-migrations gate (E00-S03-T06) ```

bot-tester commented 2026-08-30 01:31:34 +00:00

Member

Copy Link

Copy Source

agent: tester
phase: start
issue: 180
pr: 394
head_branch: feature/180
head_sha: bb3a68648a66c4049fcd4125a096b51b3c45a01a
objective: "Independently probe PR #394 for #180 ([E00-S03-T05] Migration failure produces structured diagnostic)"
acceptance:
  - "migration failure produces a structured diagnostic"
  - "the diagnostic identifies the failing migration"
approach:
  - inspect committed packages/database-postgres/src/runner.ts + ledger.ts + index.ts
  - run the implementer's suite as a baseline (read-only; never edited)
  - write an independent stub-pool behavioral probe that drives the committed runner module (apply-failure, record-failure, success/idempotent rerun)
  - cross-check CI (run 92) job statuses and collect links
constraints:
  - "never edit the implementer's tests in the same PR"

```yaml agent: tester phase: start issue: 180 pr: 394 head_branch: feature/180 head_sha: bb3a68648a66c4049fcd4125a096b51b3c45a01a objective: "Independently probe PR #394 for #180 ([E00-S03-T05] Migration failure produces structured diagnostic)" acceptance: - "migration failure produces a structured diagnostic" - "the diagnostic identifies the failing migration" approach: - inspect committed packages/database-postgres/src/runner.ts + ledger.ts + index.ts - run the implementer's suite as a baseline (read-only; never edited) - write an independent stub-pool behavioral probe that drives the committed runner module (apply-failure, record-failure, success/idempotent rerun) - cross-check CI (run 92) job statuses and collect links constraints: - "never edit the implementer's tests in the same PR" ```

kpcto added

kind

task

status

done

and removed

status

review

labels 2026-08-30 01:31:54 +00:00

kpcto closed this issue 2026-08-30 01:32:59 +00:00

bot-tester commented 2026-08-30 01:33:49 +00:00

Member

Copy Link

Copy Source

agent: tester
phase: complete
issue: 180
pr: 394
head_branch: feature/180
head_sha: bb3a68648a66c4049fcd4125a096b51b3c45a01a
verdict: approve
objective: "Independently probe PR #394 for #180 ([E00-S03-T05] Migration failure produces structured diagnostic)"
acceptance:
  - criterion: "migration failure produces a structured diagnostic"
    result: PASS
    evidence:
      - "independent stub-pool probe (my own code, /tmp/tester-probe.mjs) drove the COMMITTED packages/database-postgres/src/runner.ts under node --experimental-strip-types: a failing migration's up() throwing (pg code 42P01) rejects with MigrationFailedError whose .diagnostic is a plain object with exactly {migration, phase, cause, applied, pending}"
      - "JSON.stringify(error) round-trips via toJSON() to a structured object {name, message, diagnostic:{migration, phase, applied, pending, cause:{name, message, code}}}"
      - "non-Error cause (a thrown string 'boom') also yields a structured diagnostic with cause.value='boom' — the diagnostic is structured regardless of what is thrown"
      - "CI job 'Migration failure diagnostic (E00-S03-T05)' passes the suite's stub-pool behavioral probe on Node 24 (17 pass / 0 fail / 1 skip)"
  - criterion: "the diagnostic identifies the failing migration"
    result: PASS
    evidence:
      - "apply-failure: diagnostic.migration === 'fail-2', message === 'migration \"fail-2\" failed during apply', phase 'apply', applied ['ok-1'], pending ['fail-2','ok-3'] (failing migration named specifically, still pending, not applied)"
      - "record-failure (up succeeded, ledger insert threw code 25006): diagnostic.migration === 'fail-record', phase 'record', pending ['fail-record','ok-3'] — the diagnostic still names the failing migration even when the failure is at the record step"
      - "toJSON().diagnostic.migration matches the failing version in both phases"
  - criterion: "runner applies pending migrations exactly once (idempotent rerun, from parent #60)"
    result: PASS
    evidence:
      - "first run applied ['ok-1','ok-2'], rerun applied [] skipped ['ok-1','ok-2'] (stub-pool probe)"
independent_probe:
  method: "loaded committed runner.ts + ledger.ts with node --experimental-strip-types (no pg/node_modules needed; runner.ts uses only import-type so it strips clean); drove MigrationRunner with an in-memory stub pg Pool answering the exact ledger SQL"
  scenarios: "success+idempotent rerun, apply-failure (code 42P01), record-failure (code 25006), non-Error cause"
  result: "all assertions passed (exit 0)"
ci:
  run: "http://gitea:3000/Fabrika/PersonalBlog/actions/runs/92"
  status: "success (7/7 jobs) on head bb3a686"
  diagnostic_job: "http://gitea:3000/Fabrika/PersonalBlog/actions/runs/92/jobs/159"
  diagnostic_job_log: "17 pass / 0 fail / 1 skip — the behavioral (stub-pool) probe passes on Node 24"
  pr_link: "http://gitea:3000/Fabrika/PersonalBlog/pulls/394"
notes:
  - "the docker-gated real-stack probe SKIPS in CI (no Docker daemon in the runner) and locally here (no docker/podman/postgres available); it is the issue test-plan's 'real database' variant, documented to skip cleanly. The acceptance criteria themselves are verified behaviorally by the deterministic stub-pool probe (green in CI) and by my independent probe. Not a blocker."
  - "record-failure semantics: if up() succeeds but the ledger insert throws, the migration's SQL already ran yet it stays pending — a rerun would re-run it. This is inherent to the (no-transaction) runner and out of scope for #180 (the diagnostic correctly names the failing migration); flagged for the future ready/lock stories."
  - "constraint honored: the implementer's tests were never edited; workspace tree left clean (git status clean on feature/180)."

```yaml agent: tester phase: complete issue: 180 pr: 394 head_branch: feature/180 head_sha: bb3a68648a66c4049fcd4125a096b51b3c45a01a verdict: approve objective: "Independently probe PR #394 for #180 ([E00-S03-T05] Migration failure produces structured diagnostic)" acceptance: - criterion: "migration failure produces a structured diagnostic" result: PASS evidence: - "independent stub-pool probe (my own code, /tmp/tester-probe.mjs) drove the COMMITTED packages/database-postgres/src/runner.ts under node --experimental-strip-types: a failing migration's up() throwing (pg code 42P01) rejects with MigrationFailedError whose .diagnostic is a plain object with exactly {migration, phase, cause, applied, pending}" - "JSON.stringify(error) round-trips via toJSON() to a structured object {name, message, diagnostic:{migration, phase, applied, pending, cause:{name, message, code}}}" - "non-Error cause (a thrown string 'boom') also yields a structured diagnostic with cause.value='boom' — the diagnostic is structured regardless of what is thrown" - "CI job 'Migration failure diagnostic (E00-S03-T05)' passes the suite's stub-pool behavioral probe on Node 24 (17 pass / 0 fail / 1 skip)" - criterion: "the diagnostic identifies the failing migration" result: PASS evidence: - "apply-failure: diagnostic.migration === 'fail-2', message === 'migration \"fail-2\" failed during apply', phase 'apply', applied ['ok-1'], pending ['fail-2','ok-3'] (failing migration named specifically, still pending, not applied)" - "record-failure (up succeeded, ledger insert threw code 25006): diagnostic.migration === 'fail-record', phase 'record', pending ['fail-record','ok-3'] — the diagnostic still names the failing migration even when the failure is at the record step" - "toJSON().diagnostic.migration matches the failing version in both phases" - criterion: "runner applies pending migrations exactly once (idempotent rerun, from parent #60)" result: PASS evidence: - "first run applied ['ok-1','ok-2'], rerun applied [] skipped ['ok-1','ok-2'] (stub-pool probe)" independent_probe: method: "loaded committed runner.ts + ledger.ts with node --experimental-strip-types (no pg/node_modules needed; runner.ts uses only import-type so it strips clean); drove MigrationRunner with an in-memory stub pg Pool answering the exact ledger SQL" scenarios: "success+idempotent rerun, apply-failure (code 42P01), record-failure (code 25006), non-Error cause" result: "all assertions passed (exit 0)" ci: run: "http://gitea:3000/Fabrika/PersonalBlog/actions/runs/92" status: "success (7/7 jobs) on head bb3a686" diagnostic_job: "http://gitea:3000/Fabrika/PersonalBlog/actions/runs/92/jobs/159" diagnostic_job_log: "17 pass / 0 fail / 1 skip — the behavioral (stub-pool) probe passes on Node 24" pr_link: "http://gitea:3000/Fabrika/PersonalBlog/pulls/394" notes: - "the docker-gated real-stack probe SKIPS in CI (no Docker daemon in the runner) and locally here (no docker/podman/postgres available); it is the issue test-plan's 'real database' variant, documented to skip cleanly. The acceptance criteria themselves are verified behaviorally by the deterministic stub-pool probe (green in CI) and by my independent probe. Not a blocker." - "record-failure semantics: if up() succeeds but the ledger insert throws, the migration's SQL already ran yet it stays pending — a rerun would re-run it. This is inherent to the (no-transaction) runner and out of scope for #180 (the diagnostic correctly names the failing migration); flagged for the future ready/lock stories." - "constraint honored: the implementer's tests were never edited; workspace tree left clean (git status clean on feature/180)." ```

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

No results found.

Labels

Clear labels

agent/analyst-drafted

agent/analyst-drafted

kind

bug

kind

bug

kind

epic

kind

epic

kind

initiative

EPPP programme initiative

kind

story

kind

story

kind

task

EPPP engineering card/task decomposed from a story

kind

toil

kind

toil

loop

1

loop

1

loop

2

loop

2

loop

3

loop

3

needs/human-decision

needs/human-decision

needs/security-review

needs/security-review

risk

agent-full

risk

agent-full

risk

human-gated

risk

human-gated

risk

human-only

risk

human-only

size

l

size

l

size

m

size

m

size

s

size

s

status

blocked

status

blocked

status

done

Workflow: Done

status

in-progress

status

in-progress

status

proposed

status

proposed

status

ready

status

ready

status

review

status

review

stream

checkout

stream

checkout

stream

onboarding

stream

onboarding

stream

platform

stream

platform

tier/t0

trivial — implementer only, auto-merge

tier/t1

standard — implementer + reviewer + tester

tier/t2

complex — security if triggered, human merge

tier/t3

critical — full chain + security, human merge

No labels

kind

task

status

done

Milestone

No items

No Milestone Sprint 0

Projects

Clear projects

No projects

Assignees

Clear assignees

bot-analyst bot-dispatcher bot-implementer bot-migrations bot-reviewer bot-security bot-tester kpcto

No Assignees

6 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Fabrika/PersonalBlog#180