We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
docs(releases): noetl/server v2.4.0 — Phase B R2 5 more write endpoints - Releases.md: timeline row + per-repo noetl/server v2.4.0 entry documenting the shared-counter pattern + 5 endpoint instruments (Phase B Round 2 of noetl/server#21 / noetl/ai-meta#49). - Sessions-Log.md: 2026-06-03 late-afternoon entry with the round 2 scoreboard and Round 3/4 still ahead. Refs noetl/ai-meta#49, noetl/server#21
docs(releases): noetl/server v2.3.0 — Phase B R1 metrics surface - Releases.md: timeline row + per-repo noetl/server v2.3.0 entry documenting the Prometheus surface + POST /api/events instrumentation (Phase B Round 1 of noetl/server#21 / noetl/ai-meta#49). - Sessions-Log.md: 2026-06-03 afternoon entry covering the round 1 deliverable + verification + the 3-round Phase B roadmap still ahead. Refs noetl/ai-meta#49, noetl/server#21
docs(releases): noetl/server v2.2.1 + noetl/tools v2.17.0 - Releases.md: timeline rows for v2.2.1 (catalog null-vs-omit fix closing the Phase A round 5 drive-by) + v2.17.0 (bounded js_consume on the nats tool kind, closing noetl/ai-meta#52); per-repo noetl/server v2.2.1 row and noetl/tools v2.17.0 row. - Sessions-Log.md: 2026-06-03 morning entry covering the four-item plan — sub-issues #21 (Phase B scope) + #22 (Phase D scope) and PRs noetl/tools#14 + noetl/server#23 both merged. Refs noetl/ai-meta#49, noetl/ai-meta#52
docs(releases): noetl/server v2.2.0 + ops 3ef4013 — Phase A complete - Releases.md: timeline row + per-repo noetl/server v2.2.0 entry documenting the ui_schema port + drive-by i16/catalog_id fixes, plus the ops 3ef4013 row for the harness timestamp normalisation. - Sessions-Log.md: late-evening-14 entry — Phase A scoreboard final, 7 PRs across noetl/server + noetl/ops in 2 days, roadmap board stays In progress (Phases B–F remain), next-session options for pickup. Refs noetl/ai-meta#49
docs(releases): noetl/server v2.1.6 + ops 881e8db (#49 Phase A round 4) - Releases.md: timeline row for v2.1.6 + ops 881e8db; per-repo noetl/server section gets v2.1.6 row. - Sessions-Log.md: late-evening-13 entry flipped from Open → Shipped; Next session list now leads with noetl/server#18 (the remaining Phase A piece). Refs noetl/ai-meta#49
docs(sessions): add round 4 of #49 Phase A + roadmap-boards rule Logs the late-evening-13 session: - New rule agents/rules/roadmap-boards.md codifies projects-board discipline as the third trail alongside issues + wiki dashboard. - #49 Phase A round 4 dispatches noetl/server#19 (remove /api/runtimes for parity), noetl/ops#151 (drop now-moot harness probe), and noetl/server#18 (sub-issue tracking the full ui_schema port). Refs noetl/ai-meta#49
wiki: #49 Phase A round 3 + roadmap board updated
wiki: #49 Phase A round 2 + executions timestamp fix shipped
wiki: #49 Phase A first pass + #15 credential fix shipped
wiki: Phase 2.b blocked on #52 (js_consume tool op)
wiki: #51 outbox playbook auth-block fix shipped; Phase 2.a unblocked - Sessions-Log: new top-of-page entry covering the one-file fix (broken template helper + wrong alias → standard auth: block), the kind validation result (200 OK on claim), and the caveat about end-to-end "row → PUBLISHED" being muddied by background publishers in the kind cluster. Notes that Phase 2.a is now fully unblocked (all 3 sub-tasks done + the auth follow-up). - Releases: timeline entry for ops 6849e3c.
wiki: noetl/server v2.1.2 merged (axum 0.8 route-syntax fix)
wiki: #49 Phase C kind-validated on Rust server; axum 0.8 bug fixed - Umbrella-Rust-Server-Port: Phase C status flipped from "Rust unit-tested, kind-validation deferred" to "kind-validated on both Python AND Rust (same harness, 11/11 PASS)". Endpoint table now shows ✅ kind-validated for the Rust column on all 5 endpoints + the auth gate. - Sessions-Log: new top-of-page entry covering the diagnosis + fix (axum 0.7 → 0.8 route-syntax migration was missed in 18 places), the side-by-side deploy on kind, and the two follow- up findings (NATS auth format + NOETL_ENCRYPTION_KEY default) that were flagged but not blockers. - Releases: new noetl/server v2.1.2 row (pending merge of #14) + ops timeline entry for the kind-deployment manifest #147. - Home: #49 row flipped to "Phase C kind-validated on both Python AND Rust; identical 11/11 pass" with Phase D called out as the next big-lift piece. Ships in lockstep with noetl/server#14 + noetl/ops#147 per Rule 2b and Rule 0a.
wiki: #48 credential alias resolution shipped; parity-gaps umbrella closed - Umbrella-Rust-Worker-Parity-Gaps: Gap 2 (#48) now ✅ shipped; umbrella status flipped to CLOSED. Sub-task tracking + Recent- activity tables updated. Next-concrete-steps reframed as "this umbrella is closed; follow-ups live under the parent." - Sessions-Log: new top-of-page entry covering Gap 2 ship, end-to-end kind validation, AND the parallel session-wide disk cleanup (Mac internal 19 GB → 55 GB free; all NoETL build state + 8 user caches moved to /Volumes/X10/dev/caches with symlinks). - Releases: new noetl/worker v5.10.0 row in per-repo table + timeline rows for noetl/worker v5.10.0 + ops 6e82ff2. - Home: collapse #47 + #48 into a single ✅ closed umbrella row with the regression baseline delta noted. Ships in lockstep with noetl/worker#40 + noetl/ops#146 per Rule 2b and Rule 0a.
wiki: #47 task_sequence routed to python (Gap 1 closed) - Umbrella-Rust-Worker-Parity-Gaps: Gap 1 now ✅ shipped; the Recommendation block replaced by the actual Decision (Option B — route to python). Sub-task tracking table lists the PRs. Next-concrete-steps reframed around the remaining Gap 2 (#48 alias resolution). - Sessions-Log: new top-of-page entry covering the decision rationale (engine-level construct, 1.2k LoC + ~11 special-case sites), the implementation surface (1-line POOL_FILTER_MAP entry), kind validation results, and the pointer-bump SHAs. - Releases: new noetl/noetl v4.12.0 row in the per-repo table + the timeline rows for noetl v4.12.0 + ops d103443. - Home: #47 row strike-through with "shipped" annotation; the row stays because the umbrella also tracks #48. Ships in lockstep with noetl/noetl#662 + noetl/ops#145 per Rule 2b and Rule 0a.
wiki: Phase 2.a.2 path-based pool routing shipped - Umbrella-System-Pool-Design status matrix: Phase 2.a.2 ⏳ → ✅ (PRs noetl/noetl#661 v4.11.0 + noetl/ops#144 merged; kind- validated via consumer-delivery deltas). - Sessions-Log: new top-of-page entry covering the routing design (path wins over kind), the implementation surface (4 emit call sites + LRU cache), kind validation results, and the small outbox-playbook auth-block follow-up before end-to-end works. - Releases: timeline row for noetl/noetl v4.11.0 + ops @ 66282e7, plus a v4.11.0 row in the per-repo noetl/noetl table. - Home: active-umbrella row reflects Phase 2.a complete; remaining blockers (playbook auth fix → Phase 2.b projector → Phase 3 more playbooks) called out.
wiki: note noetl/docs#178 (ADR Implementation status block) merged Adds the docs PR to the "What landed" table on the Phase 2.a.3 session entry, and fills in the actual pointer-bump commit SHAs that were placeholders in the original commit.
wiki: Phase 2.a.3 system pool env wiring (noetl/ops#143 merged) - Umbrella-System-Pool-Design: mark Phase 2.a.3 ✅; PR ref updated from "in PR / #143 open" to "shipped / #143 merged; manifest applied to kind". - Sessions-Log: new top-of-page entry "Phase 2.a.3 keychain env wiring shipped" documenting the merge, the manifest patch (NOETL_KEYCHAIN_ENV_VARS), the new pod's verified env, and the remaining Phase 2.a.2 sub-task. - Releases: new timeline row for noetl/ops @ b6dd205. - Home: active-umbrella row updated — Phase 2.a.3 now ✅, Phase 2.a.2 server-side routing called out as the last remaining sub-task before end-to-end kind validation.
wiki: refresh diagrams to reflect current implementation state After Phase 1.a + 1.b + 2.a.1 shipped, the diagrams update to show actual state vs the original "design-only" sketches: - Home — Today's topology diagram refreshed: - noetl-server box shows both Python + Rust versions with ✅ on /api/internal/* completion - System worker pool added to the deploy map with NOETL_INTERNAL_ API_TOKEN annotation - outbox-publisher + projector marked "↓ to-be-retired" - "What's live on kind right now" callout below the diagram - Umbrella-System-Pool-Design — two new diagrams + one refresh: - NEW "Implementation status (2026-06-02)" ASCII matrix showing Phase 1.a / 1.b / 2.a.1 ✅ and 2.a.2 / 2.a.3 / 2.b / 3 / 4 ⏳ - NEW "Auth flow — Secret to API call" diagram showing the five-hop pipeline from K8s Secret through env mount, keychain-env-allowlist, AuthResolver, HTTPS, server gate - Existing system playbook execution flow diagram unchanged (the contract didn't shift) - Data-Access-Boundary — adds the auth flow diagram (same five- hop pipeline) with explicit "configuration-only, no Rust code" callout below. This is the page operators land on when wondering "how does a system playbook get authenticated." The repeated auth-flow diagram is intentional — Data-Access- Boundary is the convention page (rule-of-thumb readers); Umbrella- System-Pool-Design is the umbrella page (people picking up Phase 2 work). Both audiences benefit from the same diagram in their landing context. Per agents/rules/wiki-maintenance.md Rule 0a: diagrams update in the same change set as the work that produces them. This commit catches up the diagrams to the actual state after Phase 2.a.1 shipped.
wiki: Phase 2.a.1 system/outbox_publisher playbook shipped After noetl/ops#142 merged + ai-meta@8bf66f1 pointer bump: - Sessions-Log adds "2026-06-02 (late evening 3) — Phase 2.a.1 system/outbox_publisher playbook shipped" entry at top. Captures the playbook contract, the auth flow diagram, and the surprise that Phase 2.a.3 is configuration-only. - Umbrella-System-Pool-Design Phase 2.a system/outbox_publisher checkbox flips from pending to ✅ + adds notes about the auth alias + the routing-extension dependency (Phase 2.a.2 still pending before end-to-end validation possible). - Home dashboard #46 status: "Phase 1.a ✅ + Phase 1.b ✅ + Phase 2.a.1 ✅; Phase 2.a.2 server routing + 2.a.3 deployment env (PR #143) remain". - Releases Timeline adds noetl/ops@b77244e row. Per agents/rules/wiki-maintenance.md Rule 0a: every session lands its wiki updates in the same change set. Refs noetl/ai-meta#46 Refs noetl/ai-meta#50
wiki: Phase 1.b shipped — system worker pool deployed on kind After noetl/ops#141 (system pool deployment manifests) and noetl/ops#139 (validation rig) merged + ai-meta@8f40fc7 pointer bump: - Sessions-Log adds "2026-06-02 (late evening 2) — Phase 1.b system worker pool deployed" entry at top. Captures all four manifests, the kind validation output, the open Phase 2.a question, and the next-session plan. - Umbrella-System-Pool-Design Phase 1.b checklist flips from pending to ✅, with sub-items noting what's deferred to Phase 2.a (POOL_FILTER_MAP, server-side validation) and what's further deferred (Helm values, drift-guard test entry). - Home dashboard #46 status text updated: "Phase 1.a ✅ kind-validated (Python); Phase 1.b ✅ system pool deployed on kind; Phase 2.a playbook is next". - Releases Timeline adds the noetl/ops@a529e55 row. Per agents/rules/wiki-maintenance.md Rule 0a: every session lands its wiki updates in the same change set. Refs noetl/ai-meta#46
wiki: Phase 1.a kind-validated on Python After kind validation of noetl/noetl#659 / #660 (Python v4.10.1) and noetl/server#12 / #13 (Rust v2.1.1): - Sessions-Log adds "2026-06-02 (late evening) — Phase 1.a kind- validated on Python" entry at top. Captures the three real-world bugs found, the validation harness output, and DB-side verification. - Releases page Timeline + per-repo log gain v4.10.1 (Python fix release) and v2.1.1 (Rust fix release) rows. - Umbrella-Rust-Server-Port Phase C status: Python column flips to "kind-validated"; Rust column stays "unit-tested" (kind validation deferred to side-by-side deploy). Three-bug summary added. - Umbrella-System-Pool-Design Phase 1.a same status flip + harness link. - Home dashboard status text updated: - #49: "Phase C ✅ shipped + kind-validated on Python; Rust unit- tested, kind-validation deferred" - #46: "Phase 1.a ✅ kind-validated (Python); Phase 1.b + Phase 2 ready to start" Per agents/rules/wiki-maintenance.md Rule 0a: every session lands its wiki updates in the same change set. This bump satisfies that for the kind validation work. Refs noetl/ai-meta#46 Refs noetl/ai-meta#49
wiki: Phase C complete on both Python + Rust servers After noetl/server#12 merged (mirroring noetl/noetl#659 in Rust): - Sessions-Log adds "2026-06-02 (evening) — Phase C Rust side shipped (both servers complete)" entry at top. Captures the implementation details, the new deps (subtle, serial_test), the test counts, and the phase-status flip. - Releases page Timeline + per-repo log gain the noetl/server@fdf775a row (no version tag yet; awaits semantic-release). - Umbrella-Rust-Server-Port Phase C table — Rust column flips from ⏳ to ✅ for all 6 endpoints + auth gate + tracing spans. - Umbrella-System-Pool-Design Phase 1.a — same flip with the c94075e SHA reference for the server pointer bump. - Home dashboard — both primary umbrellas' status texts updated: - #49: "Phase C ✅ on both Python + Rust; other phases pending" - #46: "Phase 1.a ✅ on both servers; Phase 1.b + Phase 2 pending kind validation" Per agents/rules/wiki-maintenance.md Rule 0a: every session that lands meaningful cross-repo work updates the ai-meta wiki in the same change set. This bump satisfies that for noetl/server#12. Refs noetl/ai-meta#49 Refs noetl/ai-meta#46
wiki: Phase C Python side landed (noetl v4.10.0) After noetl/noetl#659 merged + tagged as v4.10.0: - Sessions-Log gets a new "2026-06-02 (evening) — Phase C Python side shipped" entry at top with the endpoint inventory, the PR link, and the next-session plan. - Releases page Timeline gains the v4.10.0 row + a per-repo entry under "noetl/noetl". - Umbrella-Rust-Server-Port Phase C table flips Python column to ✅ (5 endpoints + auth gate); Rust column stays ⏳ pending the mirror sub-issue. - Umbrella-System-Pool-Design Phase 1.a same flip + ai-meta SHA reference (cdb597d). - Home dashboard active-umbrella table status text updated — #49 shows "Phase C Python ✅; Rust mirror pending"; #46 shows "Phase 1.a Python ✅; Phase 1.b + Phase 2 pending kind validation". Per agents/rules/wiki-maintenance.md Rule 0a: every session that lands meaningful cross-repo work updates the ai-meta wiki in the same change set. This bump satisfies that for #659. Refs noetl/ai-meta#49 Refs noetl/ai-meta#46
Sessions-Log: flip ADR v2 status — in flight → merged (docs@4535a60)
add sharding sequence + system playbook execution flow diagrams Continuation of the 2026-06-02 diagram pass: 1. **Sharding sequence diagram** added to Phase F of #49 (Umbrella-Rust-Server-Port.md). Shows: - Initial /api/execute call lands on any shard via the gateway/ingress load balancer. - Subsequent shard-aware calls (eg. GET /api/executions/{id}) route by shard_id = hash(execution_id) % N. - Outbox claim distributes per-shard via system pool worker pod ownership. - Sharding rules table — what's shared (catalog, credentials) vs what's sharded (execution, event, command, outbox). - Migration path: N=1 first, then scale to N=3. 2. **System playbook execution flow** added to Phase 2 of #46 (Umbrella-System-Pool-Design.md, under system/outbox_publisher). Shows: - KEDA HTTP scaler triggers off pending-count endpoint. - System pool worker claims command from NATS. - Playbook executes 4 steps: claim_batch (HTTP) → publish_batch (NATS iterator) → mark_published (HTTP) → mark_failed (per-row failure branch). - Worker emits call.done → outbox → next iteration picks it up (bootstrap-tolerant cycle closure). - Auth gate noted (system-pool-sa-token on /api/internal/*). Together with the previously-added interlock + Python-trajectory + data-access-boundary diagrams, the dashboard now answers: - What's deployed today - How the two primary umbrellas connect - Where we're heading (Python footprint trajectory) - Why workers can't touch DB directly - How sharding will work - How a system playbook actually runs All from wiki pages a developer can scan in a few minutes.
add architectural diagrams across dashboard pages After session 2026-06-02 (late afternoon) request: "add that diagrams too" — make the architecture readable at a glance from any wiki page a developer might land on. Four diagrams added: 1. **Two-umbrella interlock** (#49 + #46) — visual of how the Rust server port's Phase C unblocks the system pool's Phase 2. Same API surface produced by one, consumed by the other. Added to: - Home.md (architecture-at-a-glance section) - Umbrella-Rust-Server-Port.md - Umbrella-System-Pool-Design.md 2. **Long-term Python trajectory** — three-column view: today / after #46 Phase 2 / long-term. Shows Python becoming a container payload, not a platform runtime. Added to: - Home.md - Umbrella-System-Pool-Design.md 3. **Data access boundary** — workers + system worker pool call server HTTP API; only the server talks to Postgres directly; external-subsystem playbooks (auth) go direct to external systems. Added to: - Data-Access-Boundary.md (convention page) 4. **Today's deploy topology** (pre-existing, kept) — gateway → server → outbox/projector + NATS → worker pools. Already on Home.md. Together these give a developer landing on Home immediately: - What's deployed today - The two primary in-flight umbrellas + how they interlock - The Python footprint trajectory Each Umbrella-* page carries its relevant subset so a developer opening a specific umbrella also gets the visual context. Issue comments mirror these diagrams: - #49 — interlock diagram (gh issue comment 4605222980) - #46 — interlock + trajectory diagrams (gh issue comment 4605227009)
prioritize Rust server port — add #49 umbrella page + dashboard promotion User directive 2026-06-02 late afternoon: "prioritize server rust port, taking into account latest architectural decisions." Filed noetl/ai-meta#49 — Rust server FastAPI parity port — with six-phase plan that bakes in the day's architectural decisions (data access boundary, system pool interlock, sharding-first, strangler-fig cutover, kind-validation per endpoint). Dashboard changes: - New page Umbrella-Rust-Server-Port.md — full phasing + constraints from current rule set + first-three-sub-issues plan + recent-activity table. - Home.md — Active-umbrella table reorganised; two PRIMARY umbrellas (#49 + #46) at the top with the interlock callout; #43, #47, #48 in their own swim lanes. Total active = 5. - _Sidebar.md — Active Umbrellas section promotes #49 + #46; closed umbrellas (#30, #45) moved to a new "Closed Umbrellas (2026-06-02)" subsection. - Sessions-Log.md — adds "2026-06-02 (late afternoon) — Rust server port prioritised" entry at top with the next-session plan (Phase C sub-issue, parity diff harness, EE-4 crate). The two PRIMARY umbrellas interlock: Phase C of #49 (server internal endpoints) UNBLOCKS Phase 2 of #46 (system playbooks). Next session opens Phase C sub-issue on noetl/server FIRST.
add Data-Access-Boundary convention page + corrected playbook examples After 2026-06-02 (afternoon) standing instruction: NoETL platform data is accessible via server API only. Workers (including system worker pool) call the API, never the DB directly. Changes: - Data-Access-Boundary.md — new convention page pointing to the authoritative rule in agents/rules/. TL;DR + why (connection pool, sharding, consistency) + auth exception + decision tree. - _Sidebar.md — adds Data Access Boundary under Conventions. - Home.md — adds Data Access Boundary to the conventions index with link reference. - Umbrella-System-Pool-Design.md: - Adds "Data access boundary" section explaining the rule. - Phase 1 split into 1.a (server-side API endpoints) and 1.b (system worker pool deployment). 1.a lists the five new /api/internal/* endpoints needed before any Phase 2 playbook can run. - Phase 2 playbook examples corrected: - system/outbox_publisher uses tool: http (claim/mark) + tool: nats (publish). - system/projector uses tool: nats (pull batch) + tool: http (project).
dashboard pivot — system playbooks become primary migration path After 2026-06-02 afternoon architecture decision: rest of Python → Rust migration goes via compilable + pluggable system playbooks on the system worker pool, not via more compiled binaries. Home.md: - Last-refreshed note updated with the pivot summary. - Active-umbrella table trimmed from 6 → 4 (closed #30 and #45 moved into Recently Closed section). - #46 marked PRIMARY MIGRATION UMBRELLA at the top of the table. - Sessions log section adds the afternoon entry pointing to the pivot. Umbrella pages: - Umbrella-Rust-Worker-Migration — marked CLOSED 2026-06-02 with successor pointer to #46. - Umbrella-Python-Services-To-Rust — marked CLOSED 2026-06-02 (same day; compiled-rewrite framing dropped within hours). - Umbrella-System-Pool-Design — fully rewritten as the primary migration umbrella. Captures expanded scope: Phase 1 (runtime), Phase 2 (publisher + projector playbooks), Phase 3 (additional system playbooks), Phase 4 (WASM compilation). Next concrete steps listed. Sessions-Log.md: - Adds "2026-06-02 (afternoon) — Architecture pivot: system playbooks" entry at the top with full context. Closes the architectural ambiguity: there is now ONE primary migration umbrella (#46), and it captures the platform-extends- itself-via-playbooks design.