Synthetic ledger in the browser workspace; opened files remain local.
Exact 20-digit numeric lexeme beside its original bytes.
An invalid calendar date blocks ordinary CSV without repairing the source.
Japanese interface with the same source and export decisions.

Inspiration

A table can survive for decades while the software around it disappears. Opening it in a newer tool can hide deleted rows, change a large identifier, guess the wrong encoding or turn an invalid date into something that looks ordinary. RETABLE explores resurrection as careful access: make an old table usable while keeping the evidence behind every interpretation.

The museum ledger in the demo is deliberately synthetic. It is a proposed use case, not a claim that a real archive was recovered or that user interviews were conducted.

What it does

RETABLE is a full browser workspace for a deliberately bounded format: dBASE III non-memo files with version byte 0x03 and C, N, D and L fields, up to 10 MiB and 20,000 physical records.

Open a local file, explicitly choose ASCII, Windows-1252, CP437 or CP850, then inspect a value beside its source bytes and offset. Numeric fields retain exact decimal text, including identifiers longer than JavaScript's safe integer range. Deleted records stay available for inspection. Invalid dates, unexpected trailer bytes and unknown logical values are surfaced rather than silently repaired.

The interface and common diagnostic explanations support English, Traditional Chinese and Japanese. Source files stay in the browser; the application has no file-upload endpoint or runtime network integration.

CSV export records a separate deleted-row decision and a formula-looking-text policy. A decision report captures those choices without embedding cell contents. A source archive embeds the complete original DBF as base64, its SHA-256, schema and every physical record's location and flag. Interpreted detail is limited to 100,000 cells and has an explicit completeness flag. CSV is an interpretation, not a lossless DBF round trip, and spreadsheet behavior is not guaranteed.

How we built it and used Kiro

This is a solo submission built through a transparent hybrid Kiro and Codex workflow. Kiro CLI 2.36.0 ran natively on Windows on the Free plan. It authored the project steering and core requirements, the structural header validator, the lazy record decoder and their tests. The work progressed through a 23-test first batch, a hardened header increment and a 149-test integration run that included the separately developed modules.

Kiro's implementation addressed resource caps, raw field-name copies, physical deletion flags, exact numeric lexemes, strict Gregorian dates and logical states. The public repository retains the root .kiro directory. The core milestones describe their own scope; they are not a claim that Kiro wrote the entire application.

Codex coordinated research and review, checked pinned independent dbfread fixtures, implemented encoding tables, portable SHA-256, exports and the three-language interface, and tested actual browser downloads. Subsequent review hardened decoder bounds and removed source contents from issue messages. Those follow-up changes are explicitly recorded as Codex review work.

The app uses dependency-free TypeScript and native browser APIs. A small Node build strips TypeScript into static JavaScript; it needs no server-side parser, paid API or API key.

Challenges and verification

The hardest boundary is between bytes and a convenient interpretation. Header byte 29 is reserved in this supported format, so it is not treated as an encoding hint. A normal CSV is blocked for invalid selected values, unselected encodings, invalid flags or unexpected trailer content. Before any export, the source digest is recomputed and checked.

The current automated suite passed 177 tests with zero failures. Independent fixtures retain their upstream provenance and MIT license; CP437 and CP850 mappings retain the Unicode notices. Actual Chrome checks covered the three languages, a 20-digit identifier and its hex bytes, encoding comparison, deleted-row choices, invalid-date blocking and downloaded CSV/archive/report files.

A separate synthetic 10,036,034-byte, 500-field, 20,000-record file was tested in Chrome. Its CSV contained all records and columns, and its unchanged DBF and archived source matched the original SHA-256. Export follow-up checks on the development machine took about 1.3 to 1.7 seconds; this is an observed local result, not a cross-device guarantee. Large exports still perform synchronous work and can briefly pause the interface.

What we learned

Preservation and usability need different outputs. A readable CSV cannot express every uncertainty in an old binary format. Keeping the complete source, a bounded interpretation and a separate decision report makes those tradeoffs inspectable instead of hiding them.

What's next

Future work could add a worker-based export pipeline, additional independently licensed format fixtures and broader encoding support. Memo fields, FoxPro, dBASE IV/VII, automated repair and DBF write-back are not implemented. Format support will expand through explicit requirements and independent examples rather than guesses.