Dois pedidos do lead (lista 2026-07) que formam um arco só:
- "[IDE] API de Publicação Nativa, como existe no RStudio ou no VSCode" — publicar um app direto do IDE para o Ruscker (estilo RStudio Connect:
publish → aparece no portal).
- "[IDE] Cloud Native Buildpacks, de modo que seja possível inspecionar o código local e já criar o Dockerfile" — o operador não escreve Dockerfile; o buildpack detecta (R/Shiny, Python/Streamlit…) e produz a imagem.
Faseamento sugerido
- Fase A — API de publicação: endpoint autenticado que recebe um bundle/imagem, cria/atualiza o spec e faz o re-pull; CLI
ruscker publish como primeiro cliente (o plugin de IDE vem depois).
- Fase B — buildpacks: integração com
pack/kpack ou detecção própria mínima (renv/requirements.txt) gerando a imagem no host de build.
Grande e transformador (muda o Ruscker de "hospeda imagens prontas" para "recebe código") — deliberadamente épico, para fatiar quando priorizado. Dependências: modelo de tokens de API por usuário (hoje só o token break-glass), storage de bundles.
Dois pedidos do lead (lista 2026-07) que formam um arco só:
publish→ aparece no portal).Faseamento sugerido
ruscker publishcomo primeiro cliente (o plugin de IDE vem depois).pack/kpack ou detecção própria mínima (renv/requirements.txt) gerando a imagem no host de build.Grande e transformador (muda o Ruscker de "hospeda imagens prontas" para "recebe código") — deliberadamente épico, para fatiar quando priorizado. Dependências: modelo de tokens de API por usuário (hoje só o token break-glass), storage de bundles.