Internal Teka proposal for the Kindo-side scope conversation (the Ron call). Teka is the Kindo MCP delivery team — so every delivery and throughput figure here is Teka-verified against Linear and the UsableMachines/mcp repo, not an open question handed elsewhere. The only items left open, marked [Kindo leadership], are genuine budget and authority decisions for the Kindo side. Last reviewed: 2026-05-19 (Teka). Kindo-side sign-off: [Kindo leadership].

Why this doc exists

Teka is requesting a scope expansion, starting June: a parallel frontend workstream running alongside existing backend integration work. This doc:

• Lays out what Teka has shipped since April 24 — verified against Kindo Linear + UsableMachines/mcp.

• Projects May's total throughput through June 1.

• Proposes adding a parallel frontend workstream without dropping backend integration velocity.

• Names the resources, budget, and support Teka would need to do this well.

• Isolates the genuine Kindo-leadership decisions — budget, access, sign-off — so the Ron call has a tight agenda.

Track record — Teka MCP delivery (April 24 → May 19)

Source: the [[Kindo Integrations Pipeline]] tracker, reconciled 2026-05-19 against Linear (Teka team) + UsableMachines/mcp.

Done — merged and prod-verified

Plus tooling: create-integration skill — Nango-entry + logo gate (#384, #387); Nango logos / provider cleanup (#382, #389).

Merged, awaiting Kindo deploy

• TEK-101 — Microsoft hybrid app-permission auth (#339)

• TEK-112 — Entra list_sign_ins timeout fix (#343)

• TEK-58 — SailPoint ISC tool-coverage expansion (#260)

Test production — Teka prod-verifying

• TEK-25 — Doppler — list_secrets schema bug found and fixed same-day (TEK-140, #399)

• TEK-12 — Freshservice (P0 — harness verification in progress)

• TEK-9 — Cyberhaven DLP — #341 / #373 (Kindo prod deploy not confirmed)

• TEK-97 — Microsoft Outlook / O365 Email

In progress

• TEK-118 — Nagios XI (#397)

• TEK-138 — Wiz output-validation mitigation (#395)

Headline numbers

Verified 2026-05-19 against Linear (Teka team) and merged PRs in UsableMachines/mcp: counting every Teka ticket that reached Done in the Apr 24 → May 19 window, 16 tickets closed — the 11 headline deliverables above plus smaller hardening, migration, and bug-fix tickets — against 26 PRs merged by Teka in the same window. Roughly 18 tickets sit at merge-or-beyond. Teka maintains these figures live in the [[Kindo Integrations Pipeline]]; this is a stated, verified track record, not an open question for the Kindo side to compute.

Projected throughput through June 1

Window: 2026-05-19 → 2026-06-01 = ~12 days remaining in May.

Extrapolating from the recent rate (~9 tickets shipped in the last week):

May total (Apr 24 → June 1) projection: ~22–30 tickets shipped to Done, depending on Kindo deploy cadence and unblocking of Test-production tickets.

Teka's read: the recent rate is sustainable for the backend workstream at current staffing — the frontend proposal below is scoped precisely so it stays that way.

[Kindo leadership] — to pressure-test the projection:

• Realistic Kindo deploy cadence for the 3 merged-awaiting tickets between now and June 1?

• Do any of the 5 blocked tickets (TEK-7, TEK-10, TEK-16, TEK-19, TEK-61) have movement projected by June 1?

The proposal — add a parallel frontend workstream starting June

Teka proposes a second concurrent workstream: Kindo platform frontend work — design, product thinking, frontend code, progressive PRs. Run in parallel to existing backend integration delivery, not as a replacement.

Why this earns its place now

• Backend integration delivery has demonstrated cadence — see above.

• The integration product surface increasingly bottlenecks on frontend polish, configuration UX, customer-onboarding flows, and visibility into what each integration actually does.

• Teka's MCP work already informs frontend product decisions (tool-surfacing, Nango catalog UX, error shapes) — a parallel frontend workstream closes the loop instead of leaving handoffs scattered.

• The Cloud's own product work (Daniel's parallel build) is already a working laboratory for frontend patterns that land cleanly into Kindo's surface.

Operating principle

Backend integration velocity must not drop. Any frontend ramp-up that costs backend throughput is a failed expansion. The resourcing plan below is designed around this constraint.

[Kindo leadership] — what frontend areas are highest-leverage for Q2 / Q3? Onboarding, integration config UX, tool-surfacing, dashboard, error visibility, customer-facing changelog? A ranking would help Teka scope the first 2–3 deliverables.

Resources & support requested

Phase 1 — Test (next ~3 months, starting June)

• Engagement scale: $30k / month to fund staffing a frontend contributor alongside existing backend work.

• Hardware: One additional laptop to support the parallel workstream.

• Codebase access: frontend repo access for the additional contributor; existing backend access stays unchanged.

• Linear: continued TEK-team ticketing, with frontend tickets distinguished by label or sub-team — to be decided jointly.

• Outcome bar: backend integration cadence unchanged from May; first 2–3 frontend deliverables shipped through the same Build → Review → Harness → Prod → Done pipeline.

Phase 2 — Proven and scaled (a few months in, once refined and aligned)

• Engagement scale: ~$100k / month once the dual-workstream model is sharpened and everyone on both sides is on board.

• Coverage: full-stack participation across integration product + platform frontend, with a defined scope-of-work co-authored by Kindo and Teka.

[Kindo leadership] — to weigh in on:

• Budget process — what's the right approval path internally?

• Codebase access scope — what level of frontend repo access (read / PR / direct) makes sense for the test phase?

• Decision-makers on the Kindo side — who needs to sign off, and what's their realistic timeline?

• Anything missing from the resource list that Kindo would need from Teka to make this work?

Open questions for the Kindo-side call

These are the load-bearing questions for the conversation. None block the immediate Ron call; getting Kindo's view on each before June would let the test phase start clean.

• Authoritative throughput — answered. 16 tickets reached Done and 26 PRs merged, Apr 24 → May 19, verified against Linear (Teka team) + UsableMachines/mcp. Teka maintains this live in the [[Kindo Integrations Pipeline]] — no Kindo-side pull needed.

• Deploy cadence — what's the realistic Kindo prod deploy rhythm over the next 4 weeks? Several Teka tickets (TEK-101, TEK-112, TEK-58, TEK-9) are merged-awaiting; clarity reshapes the June 1 projection.

• Frontend leverage areas — ranked list of frontend surfaces where Teka involvement would deliver most value first.

• Velocity-constraint threshold — if the dual-workstream model costs even 10% of backend integration velocity, does Kindo consider it a failed expansion? Naming the threshold makes the test phase easy to evaluate.

• Blocker support — of the 5 blocked tickets (Guardicore, Yardi Revolve, Cyera, Splunk SOAR, CyberArk) — which are unblock-able from the Kindo side, and on what timeline?

• Scope-expansion sign-off — who on the Kindo side owns the call on budget + frontend involvement? Preferred format for the decision (this doc, a sync, a Slack thread)?

What Teka commits to

• Honoring the velocity constraint — backend integration cadence at May 2026 levels through the test phase. Tracked weekly in the [[Kindo Integrations Pipeline]].

• Same delivery discipline — every frontend deliverable runs through the existing Build → Review → Harness → Prod → Done pipeline. Done means prod-verified.

• Transparency — this doc stays live. Delivery figures are Teka-verified and update as Linear and PRs ship; sections marked [Kindo leadership] get replaced with authoritative answers as the Kindo-side decisions land.

• Conventions cultivation — any recurring frontend pattern that earns its place lifts back into the Kindo nebula (Tech Stack, Workflows, Do's & Don'ts) the same way backend patterns already do.

Cross-links

• [[Kindo Integrations Pipeline]] — Teka's live tracker for backend MCP work; the source of the numbers above.

• [[Kindo — Tapestry]] — Kindo's living pipeline doc, where this proposal lands once accepted.

• [[Kindo — Operative Infrastructure]] — the operating-manual hub the new frontend leaves would extend.

• [[Team Tooling & Stack]] — the Linear / Slack / repo conventions the frontend workstream inherits.

• [[Teka — Kindo Engagement Revenue Plan]] — Teka's broader engagement framing.

[[Vast Memory Enterprise — Build Paper]] — sub-paper: how Teka would build a governed, multi-tenant enterprise memory layer with Kindo — the same memory engine as The Cloud's Vast Memory, with Teka as Technology Studio and Venture Partner.

Update — 2026-05-19 (Teka, end of day). Three review-clean PRs moved in a single working session, none deferred:

• TEK-140 · [PR #399](https://github.com/UsableMachines/mcp/pull/399) (Doppler list_secrets schema fix) — merged; the fix is live on the auto-deploy.

• TEK-118 · [PR #397](https://github.com/UsableMachines/mcp/pull/397) (Nagios XI) — cleared a third AI-review round: 4 more threads addressed and resolved (24 across three rounds), with the post-push review running.

• TEK-138 · [PR #395](https://github.com/UsableMachines/mcp/pull/395) (Wiz output-validation mitigation) — review-clean and approved, sitting in the merge queue.

This is the velocity constraint visible in practice: backend cadence held while review debt was cleared to zero across three integrations the same day.

Update — 2026-05-19 (Teka, day close). Extending the interim note above with the full day's delivery:

• Nagios XI ([TEK-118](https://linear.app/kindo/issue/TEK-118) · [PR #397](https://github.com/UsableMachines/mcp/pull/397)) — cleared six AI-review rounds to zero unresolved threads; 65 tests green. The integration carries the skip verification label, so it is cleared to ship on merge. Six rounds resolved in one working session — each iteration smaller than the last — is the review discipline the proposal commits to, sustained rather than claimed.

• Wiz output-validation mitigation ([TEK-138](https://linear.app/kindo/issue/TEK-138) · [PR #395](https://github.com/UsableMachines/mcp/pull/395)) — merged.

• Swimlane `update_record` ([TEK-141](https://linear.app/kindo/issue/TEK-141) · [PR #400](https://github.com/UsableMachines/mcp/pull/400)) — a customer-reported bug (Deloitte: record updates failing with a misleading "Record not found"). Diagnosed to three compounding faults and fixed the same day it was picked up — 132 tests, PR open. A second same-day customer-bug turnaround this session, after the Doppler fix noted above.

Net for the day: three review-clean PRs landed or merge-ready, one new customer fix opened. One honest gap worth naming for the Kindo-side conversation — Swimlane and Wiz are code-complete and reviewed but not harness-verified: Teka holds no Swimlane or wiz-cc credentials, so functional prod-verification needs a Kindo-opened path (the customer, or a test connection). Delivery throughput is Teka's to own; prod-verification is increasingly gated on Kindo-side credential access — a constraint the resourcing conversation should address alongside the frontend scope.