Structured pedagogical pipeline 77a00

[hadikarazi2022-droid]

Summary

Related Issues

Changes

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• CI/CD or build changes

Verification

Steps to reproduce / test

What you personally verified

Evidence

• CI passes (pnpm check && pnpm lint && npx tsc --noEmit)
• Manually tested locally
• Screenshots / recordings attached (if UI changes)

Checklist

• My code follows the project's coding style
• I have performed a self-review of my code
• I have added/updated documentation as needed
• My changes do not introduce new warnings

[wyuc]

Thanks for the contribution, @hadikarazi2022-droid — closing this for now. Several structural issues mean it can't be evaluated as a single unit; here's what would need to change for any of it to come back:

1. Two unrelated features bundled. Rate limiting and the pedagogical pipeline (lib/pedagogy/) are independent concerns and need separate PRs.

2. lib/pedagogy/ is a 664-line new architectural surface that nothing in the existing codebase calls yet. Large new modules need an issue or Discussion (Ideas category) first to align on shape and fit — please open one before submitting code.

3. The .gitignore change is destructive. It replaces the project-specific patterns (.next/, .env*, server-providers.yml, eval/*/results/, .worktrees, …) with a generic Python+Node template. Notably, server-providers.yml would no longer be ignored — that file holds API keys for self-hosted deployments, so this would create a secret-leak risk. The file is also wrapped in literal ``` markdown fences, which git treats as patterns. Please drop this hunk entirely.

4. The rate-limiter design needs scoping. A single global 35-RPM bucket shared across generateImage / generateVideo / generateTTS and every provider (OpenAI / Seedream / Grok / MiniMax / Kling / …) is unlikely to match real quotas — each provider has its own limit. If this is addressing a real symptom you're hitting, please open an issue describing it first.

5. RATE_LIMITING_IMPLEMENTATION.md at the repo root with hard-coded /workspace/lib/... paths shouldn't be committed; that content belongs in the PR description, not in-repo.

6. PR description is empty — please fill out the template (intent, changes, verification) so reviewers have context.

If you'd like to move any of these forward: open an issue (or Discussion under Ideas) per concern → align on design → submit a focused PR with the template filled out. Happy to engage there.