Skip to content

Record the improvement backlog as a file - #79

Open
DCLXAI wants to merge 2 commits into
mainfrom
docs/improvement-backlog
Open

Record the improvement backlog as a file#79
DCLXAI wants to merge 2 commits into
mainfrom
docs/improvement-backlog

Conversation

@DCLXAI

@DCLXAI DCLXAI commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Documentation only.

The previous backlog lived only in a conversation and was lost when it was compacted — which is part of why several of its findings sat unfixed long enough to be rediscovered today. This puts it on disk.

Re-derived across six lenses (honesty, silent failure, security, i18n/UX, reliability, tests) and adversarially verified: every entry had an independent pass try to refute it and fail.

40 candidates → 23 confirmed, 17 refuted. The refuted ones are listed with the reason they were killed, so they are not re-raised on the next sweep.

The three high-severity entries

finding why it matters
POST /api/leads rejects every completed diagnosis the funnel's core artifact never reaches the database
POST /api/privacy/delete-request accepts anonymous callers an irreversible hard-delete can be scheduled by anyone
retention's redaction guards can never match in production records that should be redacted are not

The first is verified end to end, by running the real engine output through the real schema shape rather than by reading the code:

schema accepts the real POST body: false
  warnings.0:    expected string, received object
  nextActions.0: expected string, received object

recommendPath() emits {ko,vi,mn,en} objects; the schema declares z.array(z.string()). useLeadStore.saveDiagnosis catches the 400, writes a local-<timestamp> lead into zustand and returns its id — so the wizard reports success and the admin inbox receives nothing.

Entries carry file:line, the concrete user- or operator-visible consequence, and the smallest fix. Delete an entry when it ships.

🤖 Generated with Claude Code

The previous backlog lived only in a conversation and was lost when that
conversation was compacted, which is part of why several of its findings sat
unfixed long enough to be rediscovered today. This puts it on disk.

Re-derived across six lenses — honesty, silent failure, security, i18n/UX,
reliability, tests — and adversarially verified: every entry had an independent
pass try to refute it and fail. 40 candidates, 23 confirmed, 17 refuted. The
refuted ones are listed with the reason they were killed, so they are not
re-raised on the next sweep.

Three are high severity. The first is the worst: POST /api/leads declares
warnings and nextActions as z.array(z.string()) while recommendPath() emits
{ko,vi,mn,en} objects, so every completed diagnosis is rejected 400 and
useLeadStore.saveDiagnosis catches it, writes a local-<timestamp> lead into
zustand and returns its id — the wizard reports success and the admin inbox
receives nothing. Verified by running the real engine output through the real
schema shape rather than by reading it: warnings.0 and nextActions.0 both fail
with "expected string, received object".

Entries carry file:line, the concrete user- or operator-visible consequence, and
the smallest fix. Delete an entry when it ships.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 31, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
kaxi Ready Ready Preview Jul 31, 2026 3:28pm

Found while assessing what the codebase does WELL, as the caveat on its strongest
design. Retrieval re-derives document eligibility from the canonical row on every
query rather than trusting the serving cache — but the predicate is restated in at
least seven places with nothing pinning them equal, and two of them have already
diverged.

Retrieval and the serving projection hardcode 180 days (eight migration files plus
serving-projection.ts:435). Governance uses 92, configurable through
KNOWLEDGE_REVIEW_AFTER_DAYS (freshness.ts:1). The user-visible consequence is that
the citation's 재검토 예정일 is +180d on the serving path (shared-openai-rag.ts:70)
and +92d on the repository path (repository.ts:144), so one document can be shown
to two users with two different review-by dates — in a product positioned on legal
accuracy.

The legacy retrieval path already parameterises the horizon from TypeScript
(pgvector-rag.ts:517 passes review_max_age_days), so the newer path regressed on
something that was previously done right.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant