slxd-coursekit 0.1.2__tar.gz

slxd_coursekit-0.1.2/.github/workflows/ci.yml

@@ -0,0 +1,23 @@
+name: ci
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  test:
+    strategy:
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v6
+      - run: uv sync --group dev
+      - run: uv run ruff check .
+      - run: uv run pytest -q
+      - name: install as a tool
+        run: |
+          uv tool install .
+          coursekit --version

slxd_coursekit-0.1.2/.github/workflows/release.yml

@@ -0,0 +1,54 @@
+name: release
+
+# A tag `vX.Y.Z` publishes that version: the package is built, attached to a GitHub release and uploaded to PyPI (trusted publishing:
+# the `pypi` environment of this repository, registered as publisher of the project on PyPI).
+on:
+  push:
+    tags: ["v*"]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v6
+      - name: the tag is the version of the package
+        run: |
+          version=$(python3 -c "import tomllib;print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])")
+          test "v$version" = "${GITHUB_REF_NAME}" || { echo "tag ${GITHUB_REF_NAME} does not match version $version"; exit 1; }
+      - run: uv sync --group dev
+      - run: uv run ruff check .
+      - run: uv run pytest -q
+      - run: uv build
+      - uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  github-release:
+    needs: build
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - uses: softprops/action-gh-release@v2
+        with:
+          files: dist/*
+          generate_release_notes: true
+
+  pypi:
+    needs: build
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - uses: pypa/gh-action-pypi-publish@release/v1

slxd_coursekit-0.1.2/.gitignore

@@ -0,0 +1,7 @@
+__pycache__/
+*.pyc
+.venv/
+dist/
+build/
+.pytest_cache/
+.ruff_cache/

slxd_coursekit-0.1.2/.python-version

@@ -0,0 +1 @@
+3.12

slxd_coursekit-0.1.2/AGENTS.md

@@ -0,0 +1,61 @@
+# AGENTS.md — coursekit (development)
+
+Instructions for any coding agent (Claude Code, opencode, Codex) working on the coursekit package
+itself. The instructions that coursekit generates for course projects live in
+`src/coursekit/templates/project/AGENTS.md`, not here.
+
+## Read first
+
+- `dev/plan.md`: the plan, its phases and the state of each step (maintainers' notes, in Spanish; not user documentation).
+- `CONTRIBUTING.md` (English) and `CONTRIBUTING.es.md` (Spanish): environment, tests, how to contribute; keep both in step.
+
+## Public repository: nothing about clients or origin
+
+- This repository is public. Never write the name of a client, a person, a tenant, an internal
+  URL, a course of a real project or any data of a real project: not in code, tests, fixtures,
+  docs, comments or commit messages.
+- Never say or imply where coursekit comes from ("a previous pipeline", "the reference project",
+  "migrated from", "as before"…). Write the package, its docs and its history as a standalone
+  product.
+- Examples and test fixtures are generic and invented (e.g. a course on strong passwords, client
+  "ACME").
+
+## Languages
+
+- Code, identifiers, comments, file names, YAML keys, skills, commands and agents: **English**.
+- CLI messages (output, errors, `--help`) speak the language of the person (`es` or `en`: `COURSEKIT_LANG`
+  in the `.env`, else `project.yaml › ui_language`, else the system's). Never write one in Python: add it
+  to `src/coursekit/lang/messages/<module>.yaml` with its `es` and `en` text and use
+  `t("<module>", "<key>", value=...)` from `coursekit.i18n` (`tests/test_i18n.py` checks both languages
+  and the `{values}`). The tests run with `COURSEKIT_LANG=en`.
+- `docs/` is the user documentation, in **English** (`docs/en/`) and **Spanish (Spain)** (`docs/es/`) with the
+  same files, and `README.md` / `README.es.md`. Commit messages and conversation with the maintainer:
+  **Spanish (Spain)**.
+- Course content formats are per language (`src/coursekit/lang/es.yaml`, `en.yaml`); never
+  hard-code a content token (section heading, objective tag, placeholder) in Python. Resource types
+  and the keys and words of the directives (`question:`, `answer: true`...) have an English **id** in the
+  code, the configuration and the manifest (`image`, `infographic`...) and the word each language writes in
+  `media_types`, `directive_keys` and `directive_words` of its `lang/<code>.yaml`: a new type or key is added to
+  every language file (`tests/test_content_words.py` checks it). The defaults and their texts are in English.
+
+## Working rules
+
+- `uv sync --group dev`, then `uv run ruff check .` and `uv run pytest -q` before every commit;
+  CI runs both on Linux, macOS and Windows (paths in messages with `as_posix()`; read git output as
+  UTF-8).
+- Production rules and numbers live in `src/coursekit/defaults/*.yaml` and reach skills as
+  `{{tokens}}` (`coursekit agents`): never write a number in a skill.
+- Every rule a project can override lives in `src/coursekit/defaults/<name>.yaml`, commented. `coursekit init`
+  copies each file to the project as `config/<name>.example.yaml` (complete, with every value; not read;
+  `init --update` refreshes it), so a new rule or a changed default reaches the examples by itself: just keep
+  its comment up to date. A new configuration file needs its name in `config.NAMES` **and** `init.CONFIG_NAMES`
+  (`tests/test_init.py` fails otherwise), and its documentation in `docs/en` and `docs/es`.
+- Documentation travels with the change: a new or changed command, option, process, configuration or rule is
+  documented in `docs/en` and `docs/es` (same files, same structure) in the same change.
+  `tests/test_docs.py` checks that both trees have the same files, that links resolve, and that
+  `docs/*/03-commands.md` mentions every command and every option of the CLI.
+- Skills, commands and agents are edited only in `src/coursekit/agentkit/`; every `{{token}}` must
+  exist in `agents.context()` (a test fails otherwise).
+- Do not commit or push unless the maintainer asks. Never force-push without explicit permission.
+- No emojis anywhere (only `★ ✔ ✘ · — ‹ ›`).
+- Do not install software on the maintainer's machine; say what to run.

slxd_coursekit-0.1.2/CLAUDE.md

@@ -0,0 +1 @@
+@AGENTS.md

slxd_coursekit-0.1.2/CONTRIBUTING.es.md

@@ -0,0 +1,180 @@
+# Contribuir a coursekit
+
+English: [CONTRIBUTING.md](CONTRIBUTING.md)
+
+## Bienvenida
+
+coursekit (paquete `slxd-coursekit`, comando `coursekit`) es una herramienta de línea de comandos que guía la producción de cursos e-learning asistida por IA: brief, diseño instruccional, redacción, revisión, multimedia, ensamblado y entrega SCORM, con personas que firman en cada punto de control. Consulta el [README](README.es.md) para la visión general y la documentación de usuario ([English](docs/en/index.md), [Español](docs/es/index.md)) para ver cómo funciona desde el lado de quien lo usa.
+
+Se agradecen contribuciones de cualquier tamaño: informes de errores, correcciones, documentación, traducciones y nuevas funciones. Esta guía explica cómo preparar el proyecto, qué debe pasar antes de dar un cambio por bueno y dónde está cada cosa.
+
+El repositorio es público. No incluyas nunca el nombre de un cliente, de una persona, de un tenant, una URL interna ni datos de un proyecto real en código, tests, fixtures, documentación, comentarios o mensajes de commit. Los ejemplos y fixtures son genéricos e inventados (por ejemplo, un curso sobre contraseñas seguras para un cliente llamado "ACME").
+
+## Preparar el entorno
+
+Necesitas Python 3.12 o 3.13 (`requires-python = ">=3.12,<3.14"`; `.python-version` fija 3.12) y [uv](https://docs.astral.sh/uv/).
+
+```bash
+git clone https://github.com/studiolxd/coursekit
+cd coursekit
+uv sync --group dev
+```
+
+`uv sync --group dev` crea `.venv` e instala el paquete y las herramientas de desarrollo (`pytest`, `ruff`). Ejecuta coursekit desde el código fuente, sin instalarlo:
+
+```bash
+uv run coursekit --version
+uv run coursekit help
+```
+
+Para probarlo como lo haría una persona usuaria, instálalo como herramienta (CI hace lo mismo con `uv tool install .`) y trabaja en una carpeta desechable fuera del repositorio:
+
+```bash
+uv tool install --editable .
+mkdir -p ~/tmp/coursekit-try && cd ~/tmp/coursekit-try
+coursekit init demo --yes --no-git --client ACME
+cd demo
+coursekit status
+```
+
+`--editable` hace que el comando instalado siga tus cambios. Al terminar: `uv tool uninstall slxd-coursekit`. Si la terminal no encuentra `coursekit` tras instalarlo, ejecuta `uv tool update-shell` y abre una terminal nueva.
+
+### Windows, macOS y Linux
+
+CI se ejecuta en los tres (consulta `.github/workflows/ci.yml`), así que un cambio tiene que funcionar en los tres:
+
+- Las rutas que se muestran en los mensajes pasan por `Path.as_posix()`, para que la salida sea igual en todas partes.
+- Lee la salida de `git` (y de cualquier otra herramienta) como UTF-8.
+- Los ficheros que genera coursekit se escriben en UTF-8 con saltos de línea `\n` (`write_text(..., encoding="utf-8", newline="\n")`).
+- Construye las rutas con `pathlib`, no concatenando cadenas con `/` o `\`.
+
+## Comprobaciones antes de cada cambio
+
+```bash
+uv run ruff check .
+uv run pytest -q
+```
+
+Ambas deben pasar; CI ejecuta las dos (más `uv tool install .` y `coursekit --version`) en Linux, macOS y Windows con cada push a `main` y cada pull request. Ruff se configura en `pyproject.toml`: longitud de línea 140, Python 3.12 como objetivo y las reglas `E`, `F`, `I` (imports), `UP` y `B`. `uv run ruff check . --fix` corrige la mayoría de los avisos de orden de imports y de estilo.
+
+`tests/conftest.py` fija `COURSEKIT_LANG=en` en todos los tests y restaura el entorno después, así que los mensajes en los tests están en inglés. Un test que necesite español lo indica de forma explícita (`monkeypatch.setenv("COURSEKIT_LANG", "es")` o `i18n.use("es")`).
+
+Además de los tests de comportamiento (`test_cli.py`, `test_course_flow.py`, `test_assemble.py`, `test_delivery.py`, `test_media.py`, `test_launch.py`, `test_setup.py`, `test_config.py`, ...), algunos tests vigilan las convenciones del proyecto y fallan si un cambio olvida una parte:
+
+| Test | Qué comprueba |
+|------|---------------|
+| `tests/test_i18n.py` | Cada mensaje de `src/coursekit/lang/messages/*.yaml` existe en `es` y `en` con los mismos `{valores}`; cada `t("módulo", "clave")` usado en el código existe en su catálogo y recibe los valores que necesita; no hay emojis en los catálogos. |
+| `tests/test_docs.py` | `docs/en` y `docs/es` tienen los mismos ficheros y la misma estructura de encabezados; los enlaces se resuelven; no hay emojis; `docs/*/03-commands.md` menciona cada comando y cada opción de la CLI; los dos README se enlazan entre sí. |
+| `tests/test_init.py` | `init.CONFIG_NAMES` es igual a `config.NAMES`; `config/<nombre>.example.yaml` es el valor por defecto completo del paquete para cada configuración. |
+| `tests/test_agents.py` | Cada skill, comando y agente se genera para cada herramienta, sin ningún `{{token}}` sin sustituir. |
+
+## Mapa del repositorio
+
+| Ruta | Qué hay |
+|------|---------|
+| `src/coursekit/cli.py` | Punto de entrada (`coursekit = "coursekit.cli:main"`): el parser, `init`, `config`, `rules`, `agents` y la gestión de errores de nivel superior. |
+| `src/coursekit/commands.py` | El resto de comandos: `register(sub)` añade cada subcomando y sus opciones; las funciones `cmd_*` llaman a los módulos de abajo. |
+| `src/coursekit/project.py`, `envfile.py`, `config.py` | Localizar el proyecto, cargar `.env` y la configuración por capas (valores del paquete, `config/`, `project.yaml`, `course.yaml`). |
+| `src/coursekit/init.py`, `setup.py`, `doctor.py` | `coursekit init` (estructura del proyecto y ficheros que mantiene al día), `setup` (herramientas de la máquina) y `doctor` (diagnóstico). |
+| `src/coursekit/course.py`, `new.py`, `sync.py`, `outline.py`, `status.py`, `states.py` | El modelo del curso, crear un curso, sincronizar el diseño aprobado con el esqueleto del contenido, leer el diseño y el estado del curso. |
+| `src/coursekit/verify.py`, `approve.py`, `fingerprint.py`, `identity.py` | Comprobar el contenido contra las reglas de producción, las firmas y las huellas que detectan cambios posteriores. |
+| `src/coursekit/agents.py`, `launch.py` | Generar skills, comandos y agentes para cada herramienta de IA (`context()` guarda los `{{tokens}}`) y lanzar las herramientas. |
+| `src/coursekit/brief.py`, `media.py`, `mediatools.py`, `voices.py`, `theme.py` | Conversión del brief, planificación y producción multimedia, voces y subtítulos, tokens del theme. |
+| `src/coursekit/assemble.py`, `directives.py`, `delivery.py`, `publish.py`, `catalog.py` | Ensamblado en la plataforma de autoría, directivas, entrega SCORM, publicación y catálogo de cursos. |
+| `src/coursekit/i18n.py` | Mensajes para personas: `t("módulo", "clave", valor=...)` y la elección del idioma. |
+| `src/coursekit/lang/` | `es.yaml` y `en.yaml`: tokens del formato de contenido del curso por idioma. `lang/messages/<módulo>.yaml`: los catálogos de mensajes de la CLI (`es` y `en`). |
+| `src/coursekit/defaults/` | Valores por defecto del paquete, comentados: `rules.yaml`, `directives.yaml`, `media.yaml`, `delivery.yaml` (un proyecto puede sobrescribirlos) y `agents.yaml` (herramienta y modelo por defecto de cada rol). |
+| `src/coursekit/agentkit/` | Origen de las skills, comandos, agentes y documentos de referencia que se generan en los proyectos de curso. |
+| `src/coursekit/templates/` | Ficheros que se copian en proyectos y cursos (`project/`, `course/`, `brief/`, `remotion/`). |
+| `src/coursekit/tools/` | Scripts auxiliares que se distribuyen con el paquete (`web2md.js`). |
+| `tests/` | La batería de tests; `tests/fixtures/` contiene datos inventados. |
+| `docs/en/`, `docs/es/` | Documentación de usuario en inglés y en español (España), con los mismos ficheros en ambos idiomas. |
+
+## Convenciones
+
+- **Idiomas.** El código, los identificadores, los comentarios, los nombres de fichero, las claves YAML, las skills, los comandos y los agentes están en inglés. Los mensajes para personas (salida, errores, `--help`) no se escriben nunca en Python: viven en los catálogos, en español e inglés. La documentación se escribe en ambos idiomas. Los mensajes de commit se escriben en español (España), como en el historial existente.
+- **Tokens de contenido.** Las palabras del formato de contenido del curso (encabezado de apartado, etiqueta de objetivo, marcador de recurso, ...) pertenecen a `src/coursekit/lang/<código>.yaml`. No las escribas fijas en Python.
+- **Sin números en las skills.** Las reglas y cifras de producción viven en `src/coursekit/defaults/*.yaml` y llegan a las skills como `{{tokens}}`.
+- **Sin emojis** en ningún sitio (código, documentación, mensajes, commits). Los únicos símbolos permitidos son `★ ✔ ✘ · — ‹ ›`.
+- **Comentarios.** Explican el porqué, no el qué; mantenlos breves, en inglés, y actualízalos junto con el código. Los valores comentados de `src/coursekit/defaults/` hacen también de documentación de cada regla para quien usa el paquete.
+- **Ejemplos y fixtures** genéricos e inventados. No copies nunca material de un proyecto real, ni siquiera en parte.
+- **Producto independiente.** Escribe el código, la documentación y el historial como un producto con entidad propia; no describas de dónde viene coursekit ni ninguna de sus partes.
+
+## Cómo hacer
+
+### Añadir un comando o una opción
+
+1. Pon la lógica en el módulo que corresponda (o en uno nuevo) y añade una función `cmd_<nombre>(args)` en `src/coursekit/commands.py`. Los comandos sobre el propio proyecto (`init`, `config`, `rules`, `agents`) están en `cli.py`.
+2. Registra el subcomando y sus opciones en `register(sub)` (`commands.py`) o en `build_parser()` (`cli.py`). Los textos de ayuda también son mensajes: `help=t("commands", "help_<nombre>")`.
+3. Para los errores que la persona puede corregir, lanza la excepción del módulo y asegúrate de que `cli.main` la captura (las excepciones de `commands.ERRORS`): escribe `coursekit: <mensaje>` en stderr y sale con código 1.
+4. Añade los mensajes (más abajo) y un test; los tests de la CLI llaman a `main([...])` de `coursekit.cli` y leen la salida con `capsys`.
+5. Documéntalo en `docs/en/03-commands.md` y `docs/es/03-commands.md`: una sección `### \`coursekit <nombre>\``, la entrada en las tablas de comandos y cada cadena de opción. `tests/test_docs.py` falla si falta un comando o una opción en alguno de los dos ficheros.
+
+### Añadir o cambiar un mensaje
+
+Los mensajes viven en `src/coursekit/lang/messages/<módulo>.yaml`, un catálogo por módulo, cada clave con los dos idiomas:
+
+```yaml
+created_env:
+  es: "ok: .env creado"
+  en: "ok: created .env"
+```
+
+Se usa como `t("setup", "created_env")`; con valores, `t("módulo", "clave", path=...)` y `{path}` en ambos textos (una llave literal se escribe `{{`). Los dos textos deben usar los mismos `{valores}`; lo comprueba `tests/test_i18n.py`, que comprueba también que cada clave usada en el código existe. Un módulo nuevo es un fichero `<módulo>.yaml` nuevo en esa carpeta.
+
+### Añadir o cambiar una regla de producción o un fichero de configuración
+
+Una regla que un proyecto puede sobrescribir vive en `src/coursekit/defaults/<nombre>.yaml`, con un comentario que diga qué hace. `coursekit init` copia cada uno de esos ficheros al proyecto como `config/<nombre>.example.yaml` (completo, coursekit no lo lee; `init --update` lo refresca), de modo que una regla nueva o un valor por defecto cambiado llegan solos a los ejemplos: basta con mantener al día su comentario.
+
+- Una regla nueva dentro de un fichero existente: añade la clave con su valor por defecto y su comentario, úsala desde el código a través de `config` y documéntala en `docs/en/04-configuration.md` y `docs/es/04-configuration.md`. Si una skill necesita el valor, añade un token a `agents.context()` (ver más abajo).
+- Un fichero de configuración nuevo: crea `defaults/<nombre>.yaml` y añade su nombre a **ambos** `config.NAMES` (`src/coursekit/config.py`) e `init.CONFIG_NAMES` (`src/coursekit/init.py`); `tests/test_init.py` falla si no. Documéntalo en las dos páginas de configuración y en `03-commands.md` si `coursekit config` debe mencionarlo.
+
+### Editar skills, comandos y agentes
+
+Edítalos solo en `src/coursekit/agentkit/` (`skills/<nombre>/SKILL.md`, `commands/<nombre>.md`, `agents/<nombre>.md`, `docs/`). No edites nunca las copias generadas dentro de un proyecto de curso. Cada `{{token}}` que uses debe existir en `agents.context()` de `src/coursekit/agents.py`; un token desconocido lanza un error y `tests/test_agents.py` falla. Los parciales empiezan por `_` y se incluyen con `{{> _nombre}}`. Para ver el resultado, ejecuta `coursekit agents` en un proyecto desechable y lee los ficheros generados.
+
+### Añadir un idioma de contenido
+
+El formato de contenido es por idioma. Como mínimo:
+
+- `src/coursekit/lang/<código>.yaml` con todos los tokens (copia `en.yaml`), incluidos `media_types` (la palabra de cada id de tipo de recurso), `directive_keys` y `directive_words`, y el código añadido a `LANGUAGES` en `src/coursekit/lang/__init__.py`. Un tipo de recurso o una clave de directiva nuevos reciben un id y una palabra en cada fichero de idioma (`tests/test_content_words.py` lo comprueba).
+- El código en `init.LANGUAGES` y sus formas de tratamiento en `init.ADDRESS`; su nombre en `agents.LANGUAGE_NAMES`; el tratamiento por defecto en `agents.context()`.
+- Una plantilla de curso: `src/coursekit/templates/course/<código>/` (`content.md`, `assessment.md`).
+- Valores por defecto que dependen del idioma: `catalog.CATALOG_NAME` y los textos de sus columnas, `setup.PIPER_DEFAULT`, `voices.LOCALES` y las voces por defecto de `voices.py`.
+- Documentación en `docs/en` y `docs/es`, y tests.
+
+El idioma de la interfaz (`ui_language`, `COURSEKIT_LANG`) es independiente: es `es` o `en` (`i18n.LANGUAGES`). Añadir uno supone añadir su texto a cada entrada de cada catálogo, y `tests/test_i18n.py` las exige todas.
+
+### Añadir documentación
+
+La documentación de usuario vive en `docs/en/` y `docs/es/`, con los mismos nombres de fichero y la misma estructura de encabezados (número y nivel). Un comando, opción, proceso, configuración o regla nuevos o modificados se documentan en los dos idiomas en el mismo cambio. Los enlaces son relativos y deben resolverse; los bloques de código no se comprueban, así que mantén exactos los comandos que contienen. Si añades una página, añádela a los dos árboles y enlázala desde `index.md`.
+
+## Pull requests y commits
+
+- Mantén los cambios pequeños y centrados: una corrección o función por pull request, sin reformateos ajenos al cambio.
+- Código, tests y documentación van juntos. Un pull request que cambia el comportamiento incluye el test que lo cubre y las actualizaciones de `docs/en` y `docs/es`.
+- Ejecuta antes `uv run ruff check .` y `uv run pytest -q`. Comprueba que la salida se lee bien en los dos idiomas en todo lo que ve una persona (`COURSEKIT_LANG=es` y `COURSEKIT_LANG=en`).
+- Los mensajes de commit se escriben en español (España): una primera línea breve que diga qué cambia y, si hace falta, los detalles después. Ejemplo: `Rutas con barras normales en los mensajes de error`.
+- No hagas force-push en ramas compartidas ni reescribas historial que otras personas ya hayan descargado.
+- No subas ficheros generados o locales: `.venv/`, `dist/`, `build/`, cachés ni ningún `.env`.
+
+## Versiones
+
+Una etiqueta `vX.Y.Z` que coincida con la versión de `pyproject.toml` ejecuta `.github/workflows/release.yml`: comprueba, construye, adjunta el wheel y la distribución de código fuente a una release de GitHub y sube a PyPI (publicación de confianza: el entorno `pypi` del repositorio es el publicador registrado en PyPI). Para publicar: sube `version`, commit, `git tag vX.Y.Z`, `git push --tags`. Los proyectos siguen la versión instalada por sí solos (el primer comando tras actualizar regenera sus ficheros gestionados y los de los agentes). La versión es el campo `version` de `pyproject.toml` (ahora `0.1.2`); `coursekit --version` la lee de los metadatos del paquete instalado y muestra `0.0.0` si se ejecuta desde un checkout sin instalar. El paquete se construye con hatchling:
+
+```bash
+uv build
+```
+
+que escribe la distribución de código fuente y el wheel en `dist/` (ignorado por git). Los cambios de versión y las publicaciones los decide el equipo mantenedor.
+
+## Informar de problemas
+
+Abre una issue en el [repositorio](https://github.com/studiolxd/coursekit). Incluye:
+
+- La salida de `coursekit --version` y cómo lo instalaste (`uv tool install`, `uv run` desde un checkout).
+- Tu sistema operativo y su versión, y la versión de Python si ejecutas desde el código fuente.
+- El comando exacto y su salida completa (añade `COURSEKIT_LANG=en` para obtener los mensajes en inglés), y la salida de `coursekit doctor` si el problema tiene que ver con las herramientas de la máquina.
+- Qué esperabas y qué ocurrió, y los pasos mínimos para reproducirlo, a ser posible en un proyecto nuevo creado con `coursekit init`.
+
+No pegues secretos ni material de cursos reales: elimina claves de API, tokens, el contenido de `.env`, URLs de sistemas internos y cualquier texto del curso de un cliente. Sustitúyelos por ejemplos inventados.

slxd_coursekit-0.1.2/CONTRIBUTING.md

@@ -0,0 +1,180 @@
+# Contributing to coursekit
+
+Español: [CONTRIBUTING.es.md](CONTRIBUTING.es.md)
+
+## Welcome
+
+coursekit (package `slxd-coursekit`, command `coursekit`) is a command-line tool that drives the production of AI-assisted e-learning courses: brief, instructional design, writing, review, media, assembly and SCORM delivery, with people signing off at every control point. See the [README](README.md) for the overview and the user documentation ([English](docs/en/index.md), [Español](docs/es/index.md)) for how it works from the user's side.
+
+Contributions of any size are welcome: bug reports, fixes, documentation, translations and new features. This guide explains how to set up the project, what must pass before a change is ready and where things live.
+
+The repository is public. Never include the name of a client, a person, a tenant, an internal URL or any data of a real project in code, tests, fixtures, docs, comments or commit messages. Examples and fixtures are generic and invented (for instance, a course on strong passwords for a client called "ACME").
+
+## Set up the environment
+
+You need Python 3.12 or 3.13 (`requires-python = ">=3.12,<3.14"`; `.python-version` pins 3.12) and [uv](https://docs.astral.sh/uv/).
+
+```bash
+git clone https://github.com/studiolxd/coursekit
+cd coursekit
+uv sync --group dev
+```
+
+`uv sync --group dev` creates `.venv` and installs the package and the development tools (`pytest`, `ruff`). Run coursekit from the source tree, without installing it:
+
+```bash
+uv run coursekit --version
+uv run coursekit help
+```
+
+To try it the way a user would, install it as a tool (CI does the same with `uv tool install .`) and work in a throwaway folder outside the repository:
+
+```bash
+uv tool install --editable .
+mkdir -p ~/tmp/coursekit-try && cd ~/tmp/coursekit-try
+coursekit init demo --yes --no-git --client ACME
+cd demo
+coursekit status
+```
+
+`--editable` makes the installed command follow your changes. When you are done: `uv tool uninstall slxd-coursekit`. If the shell does not find `coursekit` after installing, run `uv tool update-shell` and open a new terminal.
+
+### Windows, macOS and Linux
+
+CI runs on all three (see `.github/workflows/ci.yml`), so a change must work on all three:
+
+- Paths shown in messages go through `Path.as_posix()`, so the output is the same everywhere.
+- Read the output of `git` (and any other tool) as UTF-8.
+- Files coursekit generates are written as UTF-8 with `\n` line endings (`write_text(..., encoding="utf-8", newline="\n")`).
+- Build paths with `pathlib`, not by concatenating strings with `/` or `\`.
+
+## Checks before every change
+
+```bash
+uv run ruff check .
+uv run pytest -q
+```
+
+Both must pass; CI runs both (plus `uv tool install .` and `coursekit --version`) on Linux, macOS and Windows for every push to `main` and every pull request. Ruff is configured in `pyproject.toml`: line length 140, target Python 3.12, rules `E`, `F`, `I` (imports), `UP` and `B`. `uv run ruff check . --fix` fixes most import-order and style findings.
+
+`tests/conftest.py` sets `COURSEKIT_LANG=en` for every test and restores the environment afterwards, so messages in tests are in English. A test that needs Spanish says so explicitly (`monkeypatch.setenv("COURSEKIT_LANG", "es")` or `i18n.use("es")`).
+
+Besides the behaviour tests (`test_cli.py`, `test_course_flow.py`, `test_assemble.py`, `test_delivery.py`, `test_media.py`, `test_launch.py`, `test_setup.py`, `test_config.py`, ...), some tests guard the project's conventions and will fail if a change forgets a part:
+
+| Test | What it checks |
+|------|----------------|
+| `tests/test_i18n.py` | Every message of `src/coursekit/lang/messages/*.yaml` exists in `es` and `en` with the same `{values}`; every `t("module", "key")` used in the code exists in its catalog and receives the values it needs; no emojis in the catalogs. |
+| `tests/test_docs.py` | `docs/en` and `docs/es` have the same files and the same heading structure; links resolve; no emojis; `docs/*/03-commands.md` mentions every command and every option of the CLI; the two READMEs point to each other. |
+| `tests/test_init.py` | `init.CONFIG_NAMES` equals `config.NAMES`; `config/<name>.example.yaml` is the complete package default of each configuration. |
+| `tests/test_agents.py` | Every skill, command and agent is generated for every tool, with no `{{token}}` left unrendered. |
+
+## Repository map
+
+| Path | What is there |
+|------|---------------|
+| `src/coursekit/cli.py` | Entry point (`coursekit = "coursekit.cli:main"`): the parser, `init`, `config`, `rules`, `agents` and the top-level error handling. |
+| `src/coursekit/commands.py` | The rest of the commands: `register(sub)` adds each sub-command and its options; `cmd_*` functions call the modules below. |
+| `src/coursekit/project.py`, `envfile.py`, `config.py` | Finding the project, loading `.env`, and the layered configuration (package defaults, `config/`, `project.yaml`, `course.yaml`). |
+| `src/coursekit/init.py`, `setup.py`, `doctor.py` | `coursekit init` (project scaffolding and the files it keeps up to date), `setup` (machine tools) and `doctor` (diagnosis). |
+| `src/coursekit/course.py`, `new.py`, `sync.py`, `outline.py`, `status.py`, `states.py` | The course model, creating a course, syncing the approved design into the content skeleton, reading the design and the course status. |
+| `src/coursekit/verify.py`, `approve.py`, `fingerprint.py`, `identity.py` | Checking content against the production rules, sign-offs and the fingerprints that detect later changes. |
+| `src/coursekit/agents.py`, `launch.py` | Rendering skills, commands and agents for each AI tool (`context()` holds the `{{tokens}}`), and launching the tools. |
+| `src/coursekit/brief.py`, `media.py`, `mediatools.py`, `voices.py`, `theme.py` | Brief conversion, media planning and production, voices and subtitles, theme tokens. |
+| `src/coursekit/assemble.py`, `directives.py`, `delivery.py`, `publish.py`, `catalog.py` | Assembly into the authoring platform, directives, SCORM delivery, publishing and the course catalog. |
+| `src/coursekit/i18n.py` | Messages for people: `t("module", "key", value=...)` and the choice of language. |
+| `src/coursekit/lang/` | `es.yaml` and `en.yaml`: tokens of the course content format per language. `lang/messages/<module>.yaml`: the CLI message catalogs (`es` and `en`). |
+| `src/coursekit/defaults/` | Package defaults, commented: `rules.yaml`, `directives.yaml`, `media.yaml`, `delivery.yaml` (overridable by a project) and `agents.yaml` (default tool and model per role). |
+| `src/coursekit/agentkit/` | Source of the skills, commands, agents and reference docs generated into course projects. |
+| `src/coursekit/templates/` | Files copied into projects and courses (`project/`, `course/`, `brief/`, `remotion/`). |
+| `src/coursekit/tools/` | Helper scripts shipped with the package (`web2md.js`). |
+| `tests/` | The test suite; `tests/fixtures/` holds invented data. |
+| `docs/en/`, `docs/es/` | User documentation in English and Spanish (Spain), same files in both. |
+
+## Conventions
+
+- **Languages.** Code, identifiers, comments, file names, YAML keys, skills, commands and agents are in English. Messages for people (output, errors, `--help`) are never written in Python: they live in the catalogs, in Spanish and English. Documentation is written in both languages. Commit messages are written in Spanish (Spain), as in the existing history.
+- **Content tokens.** The words of the course content format (section heading, objective tag, placeholder, ...) belong to `src/coursekit/lang/<code>.yaml`. Never hard-code one in Python.
+- **No numbers in skills.** Production rules and numbers live in `src/coursekit/defaults/*.yaml` and reach skills as `{{tokens}}`.
+- **No emojis** anywhere (code, docs, messages, commit messages). The only symbols allowed are `★ ✔ ✘ · — ‹ ›`.
+- **Comments** explain why, not what; keep them short, in English, and update them with the code. The commented defaults in `src/coursekit/defaults/` double as user-facing documentation of each rule.
+- **Examples and fixtures** are generic and invented. Never copy material from a real project, not even partially.
+- **Standalone product.** Write code, docs and history as a product on its own; do not describe where coursekit or any of its parts come from.
+
+## How to
+
+### Add a command or an option
+
+1. Put the logic in the module it belongs to (or a new module) and add a `cmd_<name>(args)` function in `src/coursekit/commands.py`. Commands about the project itself (`init`, `config`, `rules`, `agents`) are in `cli.py`.
+2. Register the sub-command and its options in `register(sub)` (`commands.py`) or `build_parser()` (`cli.py`). Help texts are messages too: `help=t("commands", "help_<name>")`.
+3. For errors the person can fix, raise the module's exception and make sure it is caught in `cli.main` (the exceptions listed in `commands.ERRORS`): it prints `coursekit: <message>` to stderr and exits with 1.
+4. Add the messages (below) and a test; the CLI tests call `main([...])` from `coursekit.cli` and read output with `capsys`.
+5. Document it in `docs/en/03-commands.md` and `docs/es/03-commands.md`: a `### \`coursekit <name>\`` section, the entry in the command tables and every option string. `tests/test_docs.py` fails if a command or an option is missing from either file.
+
+### Add or change a message
+
+Messages live in `src/coursekit/lang/messages/<module>.yaml`, one catalog per module, each key with both languages:
+
+```yaml
+created_env:
+  es: "ok: .env creado"
+  en: "ok: created .env"
+```
+
+Use it as `t("setup", "created_env")`; with values, `t("module", "key", path=...)` and `{path}` in both texts (a literal brace is written `{{`). Both texts must use the same `{values}`; `tests/test_i18n.py` checks it, and also that every key used in the code exists. A new module is a new `<module>.yaml` file in that folder.
+
+### Add or change a production rule or a configuration file
+
+A rule a project can override lives in `src/coursekit/defaults/<name>.yaml`, with a comment saying what it does. `coursekit init` copies each of those files to the project as `config/<name>.example.yaml` (complete, not read by coursekit; `init --update` refreshes it), so a new rule or a changed default reaches the examples by itself: just keep its comment up to date.
+
+- A new rule inside an existing file: add the key with its default and comment, use it from the code through `config`, and document it in `docs/en/04-configuration.md` and `docs/es/04-configuration.md`. If a skill needs the value, add a token to `agents.context()` (see below).
+- A new configuration file: create `defaults/<name>.yaml` and add its name to **both** `config.NAMES` (`src/coursekit/config.py`) and `init.CONFIG_NAMES` (`src/coursekit/init.py`); `tests/test_init.py` fails otherwise. Document it in both configuration pages and in `03-commands.md` if `coursekit config` should mention it.
+
+### Edit skills, commands and agents
+
+Edit them only in `src/coursekit/agentkit/` (`skills/<name>/SKILL.md`, `commands/<name>.md`, `agents/<name>.md`, `docs/`). Never edit the generated copies inside a course project. Every `{{token}}` you use must exist in `agents.context()` in `src/coursekit/agents.py`; an unknown token raises an error and `tests/test_agents.py` fails. Partials start with `_` and are included with `{{> _name}}`. To see the result, run `coursekit agents` in a throwaway project and read the generated files.
+
+### Add a content language
+
+The content format is per language. At least:
+
+- `src/coursekit/lang/<code>.yaml` with all the tokens (copy `en.yaml`), including `media_types` (the word of each resource type id), `directive_keys` and `directive_words`, and the code added to `LANGUAGES` in `src/coursekit/lang/__init__.py`. A new resource type or directive key gets an id and a word in every language file (`tests/test_content_words.py` checks it).
+- The code in `init.LANGUAGES` and its address forms in `init.ADDRESS`; its name in `agents.LANGUAGE_NAMES`; the default address in `agents.context()`.
+- A course template: `src/coursekit/templates/course/<code>/` (`content.md`, `assessment.md`).
+- Language-dependent defaults: `catalog.CATALOG_NAME` and its column texts, `setup.PIPER_DEFAULT`, `voices.LOCALES` and the default voices in `voices.py`.
+- Documentation in both `docs/en` and `docs/es`, and tests.
+
+The language of the interface (`ui_language`, `COURSEKIT_LANG`) is separate: it is `es` or `en` (`i18n.LANGUAGES`). Adding one means adding its text to every catalog entry, and `tests/test_i18n.py` requires all of them.
+
+### Add documentation
+
+User documentation lives in `docs/en/` and `docs/es/`, with the same file names and the same heading structure (numbers and levels). A new or changed command, option, process, configuration or rule is documented in both languages in the same change. Links are relative and must resolve; fenced code blocks are not checked, so keep commands in them accurate. If you add a page, add it to both trees and link it from `index.md`.
+
+## Pull requests and commits
+
+- Keep changes small and focused: one fix or feature per pull request, without unrelated reformatting.
+- Code, tests and documentation travel together. A pull request that changes behaviour includes the test that covers it and the updates in `docs/en` and `docs/es`.
+- Run `uv run ruff check .` and `uv run pytest -q` first. Check that the output reads well in both languages for anything a person sees (`COURSEKIT_LANG=es` and `COURSEKIT_LANG=en`).
+- Commit messages are written in Spanish (Spain): a short first line saying what changes, then details if needed. Example: `Rutas con barras normales en los mensajes de error`.
+- Do not force-push shared branches, and do not rewrite history that others have pulled.
+- Do not commit generated or local files: `.venv/`, `dist/`, `build/`, caches and any `.env`.
+
+## Releases
+
+A tag `vX.Y.Z` that matches the version of `pyproject.toml` runs `.github/workflows/release.yml`: it checks, builds, attaches the wheel and the source distribution to a GitHub release and uploads to PyPI (trusted publishing: the `pypi` environment of the repository is the publisher registered on PyPI). To release: bump `version`, commit, `git tag vX.Y.Z`, `git push --tags`. Projects follow the installed version by themselves (the first command after an update regenerates their managed and agent files). The version is the `version` field in `pyproject.toml` (currently `0.1.2`); `coursekit --version` reads it from the installed package metadata and prints `0.0.0` when run from a checkout that is not installed. The package builds with hatchling:
+
+```bash
+uv build
+```
+
+which writes the source distribution and the wheel to `dist/` (ignored by git). Version bumps and releases are decided by the maintainers.
+
+## Reporting problems
+
+Open an issue in the [repository](https://github.com/studiolxd/coursekit). Include:
+
+- The output of `coursekit --version`, and how you installed it (`uv tool install`, `uv run` from a checkout).
+- Your operating system and version, and the Python version if you run from source.
+- The exact command and its complete output (add `COURSEKIT_LANG=en` to get messages in English), plus the output of `coursekit doctor` when the problem is about the machine's tools.
+- What you expected and what happened, and the smallest steps that reproduce it, ideally in a new project made with `coursekit init`.
+
+Do not paste secrets or real course material: remove API keys, tokens, `.env` contents, URLs of internal systems and any text from a client's course. Replace them with invented examples.

slxd_coursekit-0.1.2/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Studio LXD
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.