Build tsb: pandas → TypeScript migration

---
schedule: every 60m
timeout-minutes: 360
---

# Build tsb: pandas → TypeScript migration

## Goal

Build `tsb`, a complete TypeScript port of pandas, one feature at a time. This is an open-ended program — it runs continuously, always adding the next piece of pandas functionality.

### How each iteration works

1. **Read the README** at the repo root. It is the source of truth for all project parameters (package name, stack, conventions, testing requirements).
2. **Read repo-memory** (`.autoloop/`, `AGENTS.md`, `CLAUDE.md`, any planning docs) and the full issue thread (comments from other runs and steering from maintainers).
3. **Check for other running jobs.** If another autoloop job is in-flight on this program, choose *different* work that won't conflict. Check the long-running branch (`autoloop/build-tsb`) and recent commits to understand what's already in progress. Integrate cleanly when merging.
4. **Plan extensively before writing code.** On each iteration, write or update a detailed plan in repo-memory documenting: what pandas features exist, what's been ported so far, what's next, and why. The plan should reference the pandas source directly.
5. **Pick ONE feature** to implement. Start with whatever is most foundational and work outward. Each iteration adds exactly one cohesive piece — never half-finish something.
6. **Implement it fully:**
- Source code in `src/` — strict TypeScript, no `any`, no escape hatches
- Comprehensive tests — unit, property-based, fuzz where applicable. MAKE SURE TO HAVE EXACT COVERAGE OF ALL TESTS FROM Python Pandas. Duplicate all tests and add more.
- Interactive web tutorial/playground page for the feature
- Update all docs, exports, and indexes
7. **Commit with a clear message** describing what pandas feature was ported.

### First iteration

The very first iteration should:
- Set up the complete project structure: `bun init`, `tsconfig.json` (strictest settings), linting config (Biome), test config, CI workflow (GitHub Actions with Bun), Pages deployment pipeline
- Create the initial `src/index.ts` with the `tsb` package entry point
- Write a minimal "hello world" test to prove the pipeline works end to end
- Document the full migration plan in repo-memory: enumerate pandas' top-level modules and features, propose an ordering, note architectural decisions
- Commit the plan and project skeleton — no pandas features yet, just the foundation

### Key constraints

- **Package name is `tsb`.** All imports: `import { DataFrame } from 'tsb'`
- **Bun** for runtime, bundling, testing
- **Zero dependencies** for core library. Build everything pandas does from scratch. External deps only for non-core tooling (e.g. Playwright for e2e, WASM toolchains).
- **Strictest TypeScript** — `strict: true`, `noUncheckedIndexedAccess: true`, `exactOptionalPropertyTypes: true`, no `any` anywhere, no `@ts-ignore`, no `as` casts unless provably safe
- **Strictest linting** — Biome with all rules enabled, zero warnings
- **100% test coverage** — Re-use the pythons Pandas tests for everything, plus add more. Unit tests, property-based tests (fast-check), fuzz tests, Playwright e2e for the web playground
- **Interactive web playground** — every feature gets a tutorial page, deployed to GitHub Pages, WASM where useful
- **Don't worry about performance optimization** — another program handles that. Focus on correctness and completeness.
- **Pandas API parity** — match pandas' public API surface, adapted to TypeScript idioms. When in doubt, read the pandas source.

## Target

This program may modify any file in the repository. It is building the project from scratch.

Only modify these files:
- `src/**` — library source code
- `tests/**` — all test files
- `playground/**` — interactive web tutorial/playground
- `package.json` — package config
- `tsconfig.json` — TypeScript config
- `biome.json` — linter config
- `bunfig.toml` — Bun config
- `.github/workflows/**` — CI/CD pipelines (but not autoloop workflow files)
- `AGENTS.md` — agent instructions
- `CLAUDE.md` — Claude Code config
- `.autoloop/memory/**` — repo-memory for planning and coordination

Do NOT modify:
- `README.md` — source of truth, read-only for this program
- `.autoloop/programs/**` — program definitions
- `.github/ISSUE_TEMPLATE/**` — issue templates
- `.github/workflows/autoloop*` — autoloop workflow files
- `.github/workflows/sync-branches*` — sync workflow files

## Evaluation

```bash
# Type check must pass — reject iterations that introduce type errors
if command -v bunx >/dev/null 2>&1; then
if ! bunx tsc --noEmit 2>&1; then
echo '{"pandas_features_ported": null, "rejected_reason": "type check failed"}'
exit 0
fi
fi

# Tests must pass — reject iterations that break existing functionality
if command -v bun >/dev/null 2>&1; then
if ! bun test 2>&1; then
echo '{"pandas_features_ported": null, "rejected_reason": "tests failed"}'
exit 0
fi
fi

# Count TypeScript source files that contain pandas-related functionality
# (excludes config, test infra, playground scaffolding — only counts actual library code)
count=$(find src -name '*.ts' -not -name 'index.ts' -not -name '*.d.ts' 2>/dev/null | xargs grep -l 'export' 2>/dev/null | wc -l | tr -d ' ')
echo "{\"pandas_features_ported\": ${count:-0}}"
```

The metric is `pandas_features_ported`. **Higher is better.**

Start with the repository README, .autoloop/ memory, AGENTS.md, CLAUDE.md, and the full issue thread; then inspect the autoloop/build-tsb branch and recent commits for current work. The stated first iteration spans package, TypeScript, Bun, CI, playground, tests, and planning files, so identify an agreed bounded feature before coding. Done requires the selected change to pass type checking and bun test without conflicting with other work.

Vom Indexierungsmodell aus dem Issue-Text verfasst.