PAINEL_ORQUESTRACAO
Projeto Orchestrator muito longo, logo muitas janelas de texto necessarias. Preciso de um bom prompt de resumo que consiga abranger tudo o que foi discutido naquele chat, incluindo ideias centrais referentes a arquitetura do programa, a separacao em core e perifericos, as decisoes tomada, etc.
#Contexto & Objetivo Projeto: FD Sourcing – Painel de Orquestração/BI com foco inicial em SP-API (Amazon), I/O local (arquivos), e UX simples. Meta: orquestrar coletas (orders/finances/inventory), transformar e exportar dados (CSV/Parquet), com progresso, logs, cancelamento e configuração centralizada. Decisões-chave de arquitetura Desktop nativo (não web) para o painel de orquestração (UI virá depois). Execução local (sem 8n8n/NiFi) por ora; I/O em arquivos (CSV/Parquet); BigQuery ficará para depois. Cancelamento cooperativo com checkpoints frequentes (opção C). Retries granulares por fase (auth/fetch/transform/write), com backoff. Eventos padronizados (START/PHASE/PROGRESS/LOG/SUCCESS/ERROR) em JSON por linha para UI/CLI. Remoção de IAM/SigV4: SP-API agora LWA-only (Login with Amazon/OAuth2). Componentes principais (estado atual) core/contracts: TaskSpec, TaskResult, OutputArtifact, DateRange, Mode, QualityPolicy. core/events: TaskEvent com enums (EventType, Phase, LogSeverity); fábricas mk_* (ex.: mk_phase) — evita colisões de nomes. core/tasks/base: engine de tasks com: run() orquestra fases; emite eventos; captura stacktrace em arquivo; cancel cooperativo. Retries por fase; erros transitórios vs definitivos. Escrita padrão (CSV/Parquet) via adapters de arquivo. Adapters I/O (arquivos): gravação particionada por date=YYYY-MM-DD e run_id; logs em data/logs/.... Runner CLI (core/run.py): python -m core.run --task ... + filtros. --config (JSON) com defaults por task/global; --filters-file; precedência CLI > config > defaults. --list exibe registry de tasks. Tasks implementadas orders, finances, inventory — todas funcionam em MOCK; pipeline completo (fetch→transform→write). orders agora tem fetch real (OrdersV0) via adapter SP-API LWA-only quando mock:false. Mapeamento RAW estável: order_id, order_date, status, currency, total_amount, marketplace_id, (buyer_id/items_count ficam None por enquanto — exigem endpoints extras). Adapter SP-API (estado) core/adapters/spapi.py (LWA-only): obtém token com refresh_token (preferencial) ou client_credentials com scope. Implementado OrdersV0 real: GET /orders/v0/orders com MarketplaceIds, CreatedAfter/Before, MaxResultsPerPage (cap 100), pagina NextToken, retry/backoff p/ 5xx/429. Mantém MOCK para dev offline. Configuração & credenciais Variáveis de ambiente (Windows PowerShell): LWA_CLIENT_ID, LWA_CLIENT_SECRET, REFRESH_TOKEN (obrigatório para operações autorizadas). (Opcional grantless) LWA_SCOPE. Guia criado (PowerShell 5.1 vs 7, UTF-8/BOM, evitar acentos que quebrem parse). config/config.json (inicial: orders apenas): global.output_root, region, marketplace_id, rps_default. tasks.orders.filters: page_size, pages, export, mock, etc. Perfis dev/prod exemplificados (ainda sem comutação automática). Padrão de dados/artefatos Exports em: data/exports/sheets//date=YYYY-MM-DD/arquivo.csv|parquet. summary final inclui: run_id, sucesso/erro, artefatos (linhas/bytes), horários, filtros e modo. Em MOCK, tamanho típico = pages × page_size (ex.: 3×200=600). Problemas encontrados & correções Imports relativos e execução fora de pacote → trocamos por caminhos seguros/absolutos. Colisão de nomes em events (phase como campo vs método) → fábricas renomeadas para mk_*. Dataclass em task sem campos sobrescrevendo __init__ herdado → remover @dataclass de OrdersTask. Métodos abstratos/assinaturas: auth(self) sem emit (o run() emite PHASE). fetch(self) sem emit (o run() emite PHASE; progresso heurístico foi removido daqui). write(self, rows, emit) delega para BaseTask.write. PowerShell: Ternário ?: não existe no PS 5.1 → usamos if. Arquivos JSON com BOM e acentuação → padronizamos leitura utf-8-sig e strings ASCII onde preciso. Decisões finais confirmadas Fluxo LWA-only (sem IAM/SigV4). Armazenamento local (CSV/Parquet) neste momento. Cancelamento cooperativo + retries por fase. Config centralizada iniciada por orders; expandiremos para os demais domínios. UI fica para depois que a base CLI estiver estável. Pendências / Débitos técnicos (prioridade) Orders: complementar com OrderItems (para items_count) e, se permitido, BuyerInfo seguro/pseudonimizado. Finances/Inventory: implementar SP-API real (hoje só MOCK). DQ mínima: campos obrigatórios, tipos, duplicatas; warnings × abortos. Schema & Manifest: schema_version, contagem de linhas/bytes, hashes por partição. Runner QoL: métricas no SUCCESS; --output-file summary.json. Config: estender config.json para finances/inventory; opcional .env com loader stdlib. Melhorias opcionais (roadmap curto/médio) UI desktop (MVP): seleção de task/período/filtros, log em tempo real, botão Cancelar. Catálogo leve (SQLite): índice de runs/artefatos, reprocessar, retenção. Paralelismo controlado por domínio (max workers por task). Observabilidade: contadores (linhas/bytes/páginas), tempo por fase. Validação de encoding/delimitadores para CSV; compressão parquet snappy; rotação de logs. Como rodar (exemplos atuais) Listar tasks python -m core.run --list Orders (usando config, MOCK=true) python -m core.run --config .\config\config.json --task orders --start 2025-01-01 --end 2025-01-02 Orders real (sobrepondo filtros) Criar filters_real.json: {"mock": false, "page_size": 100} python -m core.run --config .\config\config.json --task orders --start 2025-09-23 --end 2025-09-24 --filters-file .\filters_real.json --verbose Dica: summary.filters.mock=false confirma SP-API real; rows>0 confirma dados recebidos. Estado final (agora) Infra de orquestração pronta e rodando. Orders: MOCK e real (OrdersV0) implementados; CSV/Parquet ok; credenciais LWA validadas. Finances/Inventory: prontos no MOCK; aguardam ligar SP-API real. Config por task ativo (orders) e runner com merge/config estável. Erros recentes (assinaturas/abstract/dataclass) corrigidos; stacktraces são salvos em data/logs.