Meeting Notes 2026 07 06

Meeting Notes — 6 July 2026

Attendees: Kris, Nathan · Status annotations added 7 July against the repo tracker.

Kris to complete the refactoring PR and finish it today — done: PR #1 (shared-core extraction, self-review fixes, tests, dev server), ready to merge
Kris to install and test the project end-to-end in Cursor and Claude, verifying data flow and authentication — backend-free path ready via TESTING.md and the local dev server; live-API pass still pending
Kris to add Codex as the next connector plugin — done: PR #2 (ascenda-codex-hooks)
Kris to structure the monorepo so individual connectors are easily extractable into public-facing repos — done in PR #1: npm workspaces, three shared packages, self-contained connector bundles
Kris to create a detailed 2-week plan with deliverables and a broader 1-month plan, to be reviewed on an ongoing basis — building blocks filed as issues #3–#8 (installer epic) and #9–#14 (open-source epic); consolidated plan to follow
Kris to flag any broken API behaviour or data inconsistencies to Nathan with a short description/example — first item drafted: the after-hours definition mismatch (client 19:00–07:00 local vs backend 08:00–18:00 UTC)
Nathan to continue building out dashboard APIs and a bare-bones dashboard framework to hand over
Nathan to be on-call to fix API issues Kris surfaces quickly
Nathan to warm up community contacts (Startmate network etc.) for early testing

The plugin/connector layer is intentionally kept "dumb" — a pure data transmission belt with minimal logic.
All heavy lifting (processing, interpretation, scoring) happens in the backend.
Data flow: IDE / cloud tool → connector → backend → dashboard and/or app.
The repo was originally generated via Cursor from the API specs; at meeting time it had not yet been run or tested against the live API. (Since then: a local mock of the API contract exists and an integration suite drives the real client through the full pairing/ingest flow; the live-API pass remains open.)

Five categories of events are tracked: creation, verification, supervision, risk, and neutral.
Kris raised the question of how raw event counts (e.g. 50 creation, 200 verification, 700 supervision over two weeks) translate into meaningful signals.
Nathan explained this is handled by a backend intelligence layer that applies smart nudging — it avoids over-notifying, learns user patterns (e.g. phone pickup times, responsiveness windows), and combines telemetry with user-provided input.

Agreed target connectors: VS Code, Claude, Cursor, and Codex.
- Codex flagged as high priority — some large engineering orgs (e.g. Virgin) mandate Codex exclusively.
Connectors will be open source solely to give users transparency and confidence about what data is sent — not to expose backend algorithms.
Users could also fork connectors to add their own tooling on top (e.g. a Pomodoro timer).
The open-source repos are a hook into the platform ecosystem — without the backend processing and dashboard, the connectors alone provide little direct value.
Plan: keep repos private initially; share with 1–2 people to validate README clarity and comprehension before any public promotion.
Repos should include tutorials and short demo videos explaining how to connect and what the tool does.

Each user is represented in the backend as a GUID — no name is stored by default.
A name is only momentarily held if the user volunteers it prior to a specialist session, then deleted after a period.
Each pairing (tool connection) is structured like an OAuth relationship off the core GUID, with consents and leases.
Telemetry from multiple tools (Cursor, VS Code, ChatGPT, etc.) is aggregated under the same user GUID but can also be broken down by tool.
Data categories (e.g. "AI engineer tooling", "developer tooling") are tagged against telemetry, enabling persona-specific views.

Dashboard ("Personal Insights Dashboard"): work-focused, shows interpreted hard data, shareable with HR or specialists — akin to viewing vehicle telematics.
App: personal, emotional reflection space — handles check-ins, nudges, and anything at a human/wellbeing level.
The personal insights dashboard is a separate product from the existing HR-facing dashboard, with a different audience and UX.
The dashboard will support granular personal views (e.g. week-over-week change) in contrast to the high-level cohort view HR sees.

Users will be able to share dashboard views with psychologists, HR, or other specialists via a code/handshake mechanism.
Users control permission levels — raw data, personal data, or a filtered view.
When a specialist (e.g. a psychologist) adopts a user as a patient, they see a richer, interpreted view with pre-diagnostic signals — without naming a condition outright.
Any personal record shared with a clinical system (PMS) is transient — held in memory for display, then offloaded to the PMS and expired.

The app is the proactive notification surface — if a user is in a problematic pattern (e.g. context-compression loops, spiralling), the backend triggers a push notification rather than waiting for them to open the dashboard.
This is backend-triggered: flags → app → surface to user.
Grounded in NASA research showing telemetry must be augmented by human self-report to be meaningful, since individual baselines differ (e.g. challenge vs. threat perception).
User input during nudges is highly valuable for personalising the model over time.

Week 1: test end-to-end data flow from connectors to API, with both Nathan and Kris using it themselves; add the Codex connector; finish refactoring into clean, extractable packages.
Week 2: build the MVP of the personal insights display layer (engineer-facing dashboard); begin sharing repos privately with a small group for feedback on comprehension and setup.
~2 weeks: target a working end-to-end MVP that can be shown to a small chosen group for early feedback.
Nathan is simultaneously warming up contacts (Startmate network) so a test community is ready when the MVP is.
Broader rollout strategy: close contacts → wider circle → anonymous communities.

Kris is using AI-assisted coding (Claude) for language-level implementation, freeing focus for architecture, product, and domain decisions.
Code philosophy: written to be readable by a junior developer — simple, not over-engineered.
Repo structure uses JavaScript packages so individual connectors can be extracted from the monorepo and published independently without breaking shared dependencies.
Nathan will act as product manager rather than reviewing code line-by-line.