@lssm/example.learning-journey-quest-challenges 0.0.0-canary-20251217073102 → 0.0.0-canary-20251217083314

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (49) hide show
  1. package/.turbo/turbo-build$colon$bundle.log +44 -16
  2. package/CHANGELOG.md +4 -4
  3. package/dist/docs/index.js +1 -0
  4. package/dist/{quest-challenges.docblock-dlZBb7sW.mjs → docs/quest-challenges.docblock.js} +3 -3
  5. package/dist/{index.d.mts → example.d.ts} +1 -4
  6. package/dist/{index.mjs → example.js} +1 -5
  7. package/dist/index.d.ts +3 -0
  8. package/dist/index.js +5 -0
  9. package/dist/libs/contracts/dist/docs/PUBLISHING.docblock.js +16 -0
  10. package/dist/libs/contracts/dist/docs/accessibility_wcag_compliance_specs.docblock.js +16 -0
  11. package/dist/libs/contracts/dist/docs/index.js +29 -0
  12. package/dist/libs/contracts/dist/docs/presentations.js +71 -0
  13. package/dist/libs/contracts/dist/docs/registry.js +44 -0
  14. package/dist/libs/contracts/dist/docs/tech/PHASE_1_QUICKSTART.docblock.js +16 -0
  15. package/dist/libs/contracts/dist/docs/tech/PHASE_2_AI_NATIVE_OPERATIONS.docblock.js +16 -0
  16. package/dist/libs/contracts/dist/docs/tech/PHASE_3_AUTO_EVOLUTION.docblock.js +16 -0
  17. package/dist/libs/contracts/dist/docs/tech/PHASE_4_PERSONALIZATION_ENGINE.docblock.js +16 -0
  18. package/dist/libs/contracts/dist/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS.docblock.js +16 -0
  19. package/dist/libs/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js +80 -0
  20. package/dist/libs/contracts/dist/docs/tech/contracts/openapi-export.docblock.js +57 -0
  21. package/dist/libs/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js +16 -0
  22. package/dist/libs/contracts/dist/docs/tech/llm/llm-integration.docblock.js +357 -0
  23. package/dist/libs/contracts/dist/docs/tech/mcp-endpoints.docblock.js +37 -0
  24. package/dist/libs/contracts/dist/docs/tech/presentation-runtime.docblock.js +16 -0
  25. package/dist/libs/contracts/dist/docs/tech/schema/README.docblock.js +20 -0
  26. package/dist/libs/contracts/dist/docs/tech/studio/learning-events.docblock.js +48 -0
  27. package/dist/libs/contracts/dist/docs/tech/studio/learning-journeys.docblock.js +79 -0
  28. package/dist/libs/contracts/dist/docs/tech/studio/platform-admin-panel.docblock.js +84 -0
  29. package/dist/libs/contracts/dist/docs/tech/studio/project-access-teams.docblock.js +45 -0
  30. package/dist/libs/contracts/dist/docs/tech/studio/project-routing.docblock.js +67 -0
  31. package/dist/libs/contracts/dist/docs/tech/studio/sandbox-unlogged.docblock.js +40 -0
  32. package/dist/libs/contracts/dist/docs/tech/studio/team-invitations.docblock.js +69 -0
  33. package/dist/libs/contracts/dist/docs/tech/studio/workspace-ops.docblock.js +47 -0
  34. package/dist/libs/contracts/dist/docs/tech/studio/workspaces.docblock.js +62 -0
  35. package/dist/libs/contracts/dist/docs/tech/telemetry-ingest.docblock.js +155 -0
  36. package/dist/libs/contracts/dist/docs/tech/templates/runtime.docblock.js +20 -0
  37. package/dist/libs/contracts/dist/docs/tech/vscode-extension.docblock.js +101 -0
  38. package/dist/libs/contracts/dist/docs/tech/workflows/overview.docblock.js +20 -0
  39. package/dist/{track-B4IVSL73.d.mts → track.d.ts} +1 -1
  40. package/dist/{track-UnyS-rkK.mjs → track.js} +1 -1
  41. package/package.json +11 -11
  42. package/tsdown.config.js +15 -11
  43. package/dist/docs/index.mjs +0 -3
  44. package/dist/docs/quest-challenges.docblock.mjs +0 -3
  45. package/dist/quest-challenges.docblock-D0rnszAi.d.mts +0 -1
  46. package/dist/track.d.mts +0 -2
  47. package/dist/track.mjs +0 -3
  48. /package/dist/docs/{index.d.mts → index.d.ts} +0 -0
  49. /package/dist/docs/{quest-challenges.docblock.d.mts → quest-challenges.docblock.d.ts} +0 -0
@@ -0,0 +1,79 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/learning-journeys.docblock.js
4
+ const tech_studio_learning_journeys_DocBlocks = [{
5
+ id: "docs.tech.studio.learning-journeys",
6
+ title: "Studio learning journeys (onboarding + coach)",
7
+ summary: "DB-backed learning journeys tracked per organization: seeded tracks/steps, event-driven progress, XP/streaks, and a Studio coach surface.",
8
+ kind: "reference",
9
+ visibility: "public",
10
+ route: "/docs/tech/studio/learning-journeys",
11
+ tags: [
12
+ "studio",
13
+ "learning",
14
+ "onboarding",
15
+ "journey",
16
+ "graphql",
17
+ "database"
18
+ ],
19
+ body: `# Studio learning journeys
20
+
21
+ Studio supports **DB-backed learning journeys** (onboarding tracks + ambient coach tips) that are advanced by **recorded learning events**.
22
+
23
+ > See also: \`/docs/tech/studio/learning-events\` for event naming + payload guardrails.
24
+
25
+ ## Scope (multi-tenancy)
26
+
27
+ - Progress is tracked **per organization** (tenant/workspace), via a \`Learner\` record keyed by \`(userId, organizationId)\`.
28
+ - Learning events are stored as \`StudioLearningEvent\` under the Studio DB schema, scoped to an organization (optionally a project).
29
+
30
+ ## Persistence model (Prisma)
31
+
32
+ Learning journey progress lives in the \`lssm_learning\` schema:
33
+
34
+ - \`Learner\` — one per \`(userId, organizationId)\`
35
+ - \`OnboardingTrack\` — seeded track definitions (trackKey, name, metadata)
36
+ - \`OnboardingStep\` — seeded step definitions (stepKey, completionCondition, xpReward, metadata)
37
+ - \`OnboardingProgress\` — learner × track progress (progress %, xpEarned, completedAt, dismissedAt)
38
+ - \`OnboardingStepCompletion\` — append-only completion records (stepKey, status, xpEarned, completedAt)
39
+
40
+ ## Track definition source (spec-first)
41
+
42
+ - Canonical track specs live in \`@lssm/example.learning-journey-registry\`.
43
+ - The Studio API seeds/updates the DB definitions via an idempotent “ensure tracks” routine.
44
+ - The DB is kept aligned with track specs (stale steps are removed) to prevent drift and unblock completion.
45
+
46
+ ## Progress advancement (event-driven)
47
+
48
+ 1) UI records an event via GraphQL \`recordLearningEvent\`
49
+ 2) Backend creates \`StudioLearningEvent\`
50
+ 3) Backend advances onboarding by matching the new event against step completion conditions
51
+ 4) Backend persists step completions and recomputes:
52
+ - \`progress\` percentage
53
+ - \`xpEarned\` (including streak/completion bonuses when configured)
54
+ - track completion state (\`completedAt\`)
55
+
56
+ ## GraphQL API (Studio)
57
+
58
+ - \`myOnboardingTracks(productId?, includeProgress?)\`
59
+ - returns all tracks + optional progress for the current learner
60
+ - \`myOnboardingProgress(trackKey)\`
61
+ - returns progress + step completion list for a single track
62
+ - \`dismissOnboardingTrack(trackKey)\`
63
+ - marks a track dismissed for the learner (prevents auto-coach)
64
+
65
+ ## UI routes/surfaces (web)
66
+
67
+ - \`/studio/learning\` — learning hub (track list + progress widget)
68
+ - \`/studio/learning/{trackKey}\` — track detail (steps + map)
69
+ - Studio shell mounts a **coach sheet** that can auto-open for incomplete, non-dismissed onboarding.
70
+
71
+ ## Security + data hygiene
72
+
73
+ - Do not put secrets/PII in \`payload\` fields of learning events.
74
+ - Prefer shallow payload filters (small, stable keys).
75
+ `
76
+ }];
77
+ registerDocBlocks(tech_studio_learning_journeys_DocBlocks);
78
+
79
+ //#endregion
@@ -0,0 +1,84 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/platform-admin-panel.docblock.js
4
+ const tech_studio_platform_admin_panel_DocBlocks = [{
5
+ id: "docs.tech.studio.platform-admin-panel",
6
+ title: "Studio Platform Admin Panel",
7
+ summary: "How PLATFORM_ADMIN organizations manage tenant orgs and integration connections without session switching.",
8
+ kind: "reference",
9
+ visibility: "public",
10
+ route: "/docs/tech/studio/platform-admin-panel",
11
+ tags: [
12
+ "studio",
13
+ "admin",
14
+ "multi-tenancy",
15
+ "integrations",
16
+ "better-auth"
17
+ ],
18
+ body: `# Studio Platform Admin Panel
19
+
20
+ ContractSpec Studio exposes a dedicated **Platform Admin Panel** for users whose **active organization** has:
21
+
22
+ - \`Organization.type = PLATFORM_ADMIN\`
23
+
24
+ The UI route is:
25
+
26
+ - \`/studio/admin\`
27
+
28
+ ## Authorization model (no org switching)
29
+
30
+ Platform admins **remain in their own organization**. Cross-tenant actions are always explicit and scoped:
31
+
32
+ - Admin operations require an explicit \`targetOrganizationId\`.
33
+ - No session / activeOrganizationId switching is performed as part of admin operations.
34
+
35
+ ## Integrations management
36
+
37
+ The admin panel manages the full ContractSpec Integrations system:
38
+
39
+ - Lists all shipped \`IntegrationSpec\` entries (registry built via \`createDefaultIntegrationSpecRegistry()\`).
40
+ - CRUD \`IntegrationConnection\` records for a selected tenant org.
41
+
42
+ ### Secrets (reference-only + write-only)
43
+
44
+ The admin UI supports two modes:
45
+
46
+ - **Reference-only (BYOK)**: store only \`secretProvider\` + \`secretRef\`.
47
+ - **Write-only provisioning/rotation**: paste a raw secret payload; server writes to the selected backend and stores the resulting reference. The secret value is **never returned or displayed**.
48
+
49
+ Supported backends:
50
+
51
+ - Env overrides (\`env://...\`)
52
+ - Google Cloud Secret Manager (\`gcp://...\`)
53
+ - AWS Secrets Manager (\`aws://secretsmanager/...\`)
54
+ - Scaleway Secret Manager (\`scw://secret-manager/...\`)
55
+
56
+ ## Better Auth Admin plugin
57
+
58
+ The panel uses the Better Auth **Admin plugin** for user operations (list users, impersonation):
59
+
60
+ - Client calls use \`authClient.admin.*\`.
61
+ - Server-side, ContractSpec enforces that users in a PLATFORM_ADMIN active org have \`User.role\` containing \`admin\` so Better Auth Admin endpoints authorize.
62
+
63
+ ## GraphQL surface
64
+
65
+ The platform-admin GraphQL operations are guarded by the active org type and include:
66
+
67
+ - \`platformAdminOrganizations(search, limit, offset)\`
68
+ - \`platformAdminIntegrationSpecs\`
69
+ - \`platformAdminIntegrationConnections(input: { targetOrganizationId, category?, status? })\`
70
+ - \`platformAdminIntegrationConnectionCreate(input)\`
71
+ - \`platformAdminIntegrationConnectionUpdate(input)\`
72
+ - \`platformAdminIntegrationConnectionDelete(targetOrganizationId, connectionId)\`
73
+
74
+ ## Key implementation files
75
+
76
+ - Auth + role enforcement: \`packages/bundles/contractspec-studio/src/application/services/auth.ts\`
77
+ - Admin GraphQL module: \`packages/bundles/contractspec-studio/src/infrastructure/graphql/modules/platform-admin.ts\`
78
+ - Integrations admin service: \`packages/bundles/contractspec-studio/src/modules/platform-integrations/index.ts\`
79
+ - Web route: \`packages/apps/web-landing/src/app/(app-customer)/studio/admin/*\`
80
+ `
81
+ }];
82
+ registerDocBlocks(tech_studio_platform_admin_panel_DocBlocks);
83
+
84
+ //#endregion
@@ -0,0 +1,45 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/project-access-teams.docblock.js
4
+ const tech_studio_project_access_teams_DocBlocks = [{
5
+ id: "docs.tech.studio.project-access-teams",
6
+ title: "Studio Project Access via Teams",
7
+ summary: "Projects live under organizations; team sharing refines access with an admin/owner override.",
8
+ kind: "reference",
9
+ visibility: "public",
10
+ route: "/docs/tech/studio/project-access-teams",
11
+ tags: [
12
+ "studio",
13
+ "projects",
14
+ "teams",
15
+ "rbac",
16
+ "access-control"
17
+ ],
18
+ body: `# Studio Project Access via Teams
19
+
20
+ Studio access control is **organization-first** with optional **team-based sharing**.
21
+
22
+ ## Data model
23
+
24
+ - \`Team\` and \`TeamMember\` define team membership inside an organization.
25
+ - \`StudioProject\` is owned by an organization.
26
+ - \`StudioProjectTeam\` links projects to 0..N teams.
27
+
28
+ ## Access rules
29
+
30
+ - **Admins/owners**: always have access to all projects in the organization.
31
+ - **Org-wide projects**: if a project has **no team links**, all organization members can access it.
32
+ - **Team-scoped projects**: if a project has **one or more team links**, a user must be a member of at least one linked team.
33
+
34
+ ## GraphQL surfaces
35
+
36
+ - Read:\n - \`myStudioProjects\` (returns only projects you can access)\n - \`studioProjectBySlug(slug)\` (enforces the same access rules)\n - \`myTeams\`\n - \`projectTeams(projectId)\`\n\n- Write:\n - \`createStudioProject(input.teamIds?)\` (teamIds optional)\n - \`setProjectTeams(projectId, teamIds)\` (admin-only)\n
37
+ ## Related\n+\n+- Team administration + invitations: see \`/docs/tech/studio/team-invitations\`.\n+
38
+ ## Notes
39
+
40
+ Payloads and events must avoid secrets/PII. For Sandbox, the model remains local-first and unlogged.
41
+ `
42
+ }];
43
+ registerDocBlocks(tech_studio_project_access_teams_DocBlocks);
44
+
45
+ //#endregion
@@ -0,0 +1,67 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/project-routing.docblock.js
4
+ const tech_studio_project_routing_DocBlocks = [{
5
+ id: "docs.tech.studio.project-routing",
6
+ title: "Studio Project Routing",
7
+ summary: "Studio uses slugged, project-first routes: /studio/{projectSlug}/* with canonical slug redirects and soft-deleted projects hidden.",
8
+ kind: "reference",
9
+ visibility: "public",
10
+ route: "/docs/tech/studio/project-routing",
11
+ tags: [
12
+ "studio",
13
+ "routing",
14
+ "projects",
15
+ "slug",
16
+ "redirects"
17
+ ],
18
+ body: `# Studio Project Routing
19
+
20
+ ContractSpec Studio uses a **project-first URL scheme**:
21
+
22
+ - \`/studio/projects\` — create, select, and delete projects.
23
+ - \`/studio/{projectSlug}/*\` — project modules (canvas/specs/deploy/integrations/evolution/learning).
24
+ - \`/studio/learning\` — learning hub that does not require selecting a project.
25
+
26
+ ## Studio layout shell
27
+
28
+ Studio routes are wrapped in a dedicated **Studio app shell** (header + footer) that provides in-app navigation (Projects/Learning/Teams), organization switching, and account actions.
29
+
30
+ Project module routes (\`/studio/{projectSlug}/*\`) render their own module shell (\`WorkspaceProjectShellLayout\`). When combined with the global Studio header, the project shell uses a **sticky header offset** to avoid overlapping sticky headers.
31
+
32
+ ## Slug behavior (rename-safe)
33
+
34
+ - Each project has a \`slug\` stored in the database (\`StudioProject.slug\`).
35
+ - When a project name changes, Studio **updates the slug** and stores the previous slug as an alias (\`StudioProjectSlugAlias\`).
36
+ - Requests to an alias slug are **redirected to the canonical slug**.
37
+
38
+ GraphQL entrypoint:
39
+
40
+ - \`studioProjectBySlug(slug: String!)\` returns:
41
+ - \`project\`
42
+ - \`canonicalSlug\`
43
+ - \`wasRedirect\`
44
+
45
+ ## Deletion behavior (soft delete)
46
+
47
+ Projects are **soft-deleted**:
48
+
49
+ - \`deleteStudioProject(id: String!)\` sets \`StudioProject.deletedAt\`.
50
+ - All listings and access checks filter \`deletedAt = null\`.
51
+ - Soft-deleted projects are treated as “not found” in Studio routes and GraphQL access checks.
52
+
53
+ ## Available modules for a selected project
54
+
55
+ The following project modules are expected under \`/studio/{projectSlug}\`:
56
+
57
+ - \`/canvas\` — Visual builder canvas (stored via overlays and canvas versions).
58
+ - \`/specs\` — Spec editor (stored as \`StudioSpec\`).
59
+ - \`/deploy\` — Deployments history + triggers (stored as \`StudioDeployment\`).
60
+ - \`/integrations\` — Integrations scoped to project (stored as \`StudioIntegration\`).
61
+ - \`/evolution\` — Evolution sessions (stored as \`EvolutionSession\`).
62
+ - \`/learning\` — Project learning activity.
63
+ `
64
+ }];
65
+ registerDocBlocks(tech_studio_project_routing_DocBlocks);
66
+
67
+ //#endregion
@@ -0,0 +1,40 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/sandbox-unlogged.docblock.js
4
+ const tech_studio_sandbox_unlogged_DocBlocks = [{
5
+ id: "docs.tech.studio.sandbox.unlogged",
6
+ title: "Sandbox (unlogged) vs Studio (authenticated)",
7
+ summary: "The sandbox is a lightweight, unlogged surface that mirrors Studio navigation without auth or analytics.",
8
+ kind: "reference",
9
+ visibility: "public",
10
+ route: "/docs/tech/studio/sandbox-unlogged",
11
+ tags: [
12
+ "studio",
13
+ "sandbox",
14
+ "privacy",
15
+ "analytics"
16
+ ],
17
+ body: `## Sandbox guarantees
18
+
19
+ - Route: \`/sandbox\`
20
+ - **No auth requirement**
21
+ - **No PostHog init**
22
+ - **No Vercel Analytics**
23
+ - Local-only state (in-browser runtime + localStorage where needed)
24
+
25
+ ## What Sandbox is for
26
+
27
+ - Try templates and feature modules safely
28
+ - Preview specs/builder/evolution/learning
29
+ - Produce copyable CLI commands (no side effects)
30
+
31
+ ## What Sandbox is *not* for
32
+
33
+ - Persisted projects/workspaces
34
+ - Real deployments
35
+ - Organization-scoped integrations (unless explicitly enabled later)
36
+ `
37
+ }];
38
+ registerDocBlocks(tech_studio_sandbox_unlogged_DocBlocks);
39
+
40
+ //#endregion
@@ -0,0 +1,69 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/team-invitations.docblock.js
4
+ const tech_studio_team_invitations_DocBlocks = [{
5
+ id: "docs.tech.studio.team-invitations",
6
+ title: "Studio Teams & Invitations",
7
+ summary: "Admin-only team management and email invitation flow to join an organization and optionally a team.",
8
+ kind: "reference",
9
+ visibility: "public",
10
+ route: "/docs/tech/studio/team-invitations",
11
+ tags: [
12
+ "studio",
13
+ "teams",
14
+ "invitations",
15
+ "access-control",
16
+ "onboarding"
17
+ ],
18
+ body: `# Studio Teams & Invitations
19
+
20
+ Studio uses **organization membership** as the base access model. Teams are optional and used to refine access to projects.
21
+
22
+ ## Who can manage teams?
23
+
24
+ - **Admins/owners only**: create, rename, delete teams; manage project team access; issue invitations.
25
+
26
+ ## Invitation data model
27
+
28
+ - \`Invitation\` rows are stored under an organization and target an **email** address.\n
29
+ - An invitation can optionally target a \`teamId\`, which will grant the user membership in that team upon acceptance.
30
+
31
+ Key fields:
32
+ - \`email\`: invited address (must match the accepting user's account email)\n
33
+ - \`status\`: \`pending | accepted | declined | expired\`\n
34
+ - \`teamId?\`: optional team to join\n
35
+ - \`inviterId\`: user who issued the invitation
36
+
37
+ ## GraphQL surfaces
38
+
39
+ - Team CRUD (admin-only):\n
40
+ - \`createTeam(name)\`\n
41
+ - \`renameTeam(teamId, name)\`\n
42
+ - \`deleteTeam(teamId)\`\n
43
+
44
+ - Invitations (admin-only):\n
45
+ - \`organizationInvitations\`\n
46
+ - \`inviteToOrganization(email, role?, teamId?)\` → returns \`inviteUrl\` and whether an email was sent
47
+
48
+ ## Accepting an invitation
49
+
50
+ The invite link is served as:\n
51
+ - \`/invite/{invitationId}\`
52
+
53
+ Acceptance rules:
54
+ - The user must be authenticated.\n
55
+ - The authenticated user’s email must match \`Invitation.email\`.\n
56
+ - If not already a member, create \`Member(userId, organizationId, role)\`.\n
57
+ - If \`teamId\` is present, ensure \`TeamMember(teamId, userId)\`.\n
58
+ - Mark invitation \`status='accepted'\` and set \`acceptedAt\`.\n
59
+ - Set \`activeOrganizationId\` for the session so \`/studio/*\` routes work immediately.
60
+
61
+ ## Email delivery
62
+
63
+ - If \`RESEND_API_KEY\` is set, the system attempts to send an email.\n
64
+ - Otherwise, the UI uses the returned \`inviteUrl\` for manual copy/share.
65
+ `
66
+ }];
67
+ registerDocBlocks(tech_studio_team_invitations_DocBlocks);
68
+
69
+ //#endregion
@@ -0,0 +1,47 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/workspace-ops.docblock.js
4
+ const tech_studio_workspace_ops_DocBlocks = [{
5
+ id: "docs.tech.studio.workspace_ops",
6
+ title: "Workspace ops (repo-linked): list / validate / deps / diff",
7
+ summary: "Read-only repo operations used by Studio to inspect and validate a linked ContractSpec workspace.",
8
+ kind: "reference",
9
+ visibility: "mixed",
10
+ route: "/docs/tech/studio/workspace-ops",
11
+ tags: [
12
+ "studio",
13
+ "repo",
14
+ "workspace",
15
+ "validate",
16
+ "diff"
17
+ ],
18
+ body: `## API surface (api-contractspec)
19
+
20
+ Base: \`/api/workspace-ops\`
21
+
22
+ These endpoints are **read-only** in v1 and never push to git:
23
+
24
+ - \`GET /api/workspace-ops/:integrationId/config?organizationId=\`
25
+ - \`GET /api/workspace-ops/:integrationId/specs?organizationId=\`
26
+ - \`POST /api/workspace-ops/:integrationId/validate\` (body: organizationId, files?, pattern?)
27
+ - \`POST /api/workspace-ops/:integrationId/deps\` (body: organizationId, pattern?)
28
+ - \`POST /api/workspace-ops/:integrationId/diff\` (body: organizationId, specPath, baseline?, breakingOnly?)
29
+
30
+ ## Repo resolution
31
+
32
+ - The repo root is resolved from the Studio Integration (\`IntegrationProvider.GITHUB\`) config:
33
+ - \`config.repoCachePath\` (preferred) or \`config.localPath\`
34
+ - Resolution is constrained to \`CONTRACTSPEC_REPO_CACHE_DIR\` (default: \`/tmp/contractspec-repos\`)
35
+
36
+ ## Intended UX
37
+
38
+ - Studio Assistant can run these checks and present results as suggestions.
39
+ - Users can copy equivalent CLI commands for local runs:
40
+ - \`contractspec validate\`
41
+ - \`contractspec deps\`
42
+ - \`contractspec diff --baseline <ref>\`
43
+ `
44
+ }];
45
+ registerDocBlocks(tech_studio_workspace_ops_DocBlocks);
46
+
47
+ //#endregion
@@ -0,0 +1,62 @@
1
+ import { registerDocBlocks } from "../../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/studio/workspaces.docblock.js
4
+ const tech_studio_workspaces_DocBlocks = [{
5
+ id: "docs.tech.studio.workspaces",
6
+ title: "Studio projects, teams, environments",
7
+ summary: "Organization-first Studio: projects live under an organization; teams refine access; projects deploy to multiple environments.",
8
+ kind: "reference",
9
+ visibility: "mixed",
10
+ route: "/docs/tech/studio/workspaces",
11
+ tags: [
12
+ "studio",
13
+ "projects",
14
+ "teams",
15
+ "rbac",
16
+ "environments"
17
+ ],
18
+ body: `## Concepts
19
+
20
+ - **Organization**: the primary grouping boundary for Studio projects.
21
+ - **Project**: one application (specs, overlays, deployments, integrations, evolution, learning).
22
+ - **Team**: refines who can see/edit a project within an organization.
23
+ - **Environment**: deployment target (Development / Staging / Production).
24
+
25
+ ## Project access (teams + admin override)
26
+
27
+ Studio uses multi-team sharing to refine access:
28
+
29
+ - **Admins/owners** can access all projects.
30
+ - If a project is shared with **no teams**, it is **org-wide** (all org members).
31
+ - If a project is shared with **one or more teams**, it is visible to:
32
+ - admins/owners, and
33
+ - members of any linked team.
34
+
35
+ ## Current persistence (DB + GraphQL)
36
+
37
+ - DB (Prisma): \`StudioProject\`, \`Team\`, \`TeamMember\`, \`StudioProjectTeam\`
38
+ - GraphQL:
39
+ - \`myStudioProjects\`
40
+ - \`createStudioProject(input.teamIds?)\`
41
+ - \`myTeams\`
42
+ - \`projectTeams(projectId)\`
43
+ - \`setProjectTeams(projectId, teamIds)\`
44
+
45
+ ## UI shell behavior
46
+
47
+ Studio and Sandbox both use a shared shell:
48
+
49
+ - Project selector → Module navigation → Environment selector
50
+ - Always-on Assistant button (floating)
51
+ - Learning journey progress (Studio persists learning events; Sandbox stays local-only)
52
+
53
+ ## Routing
54
+
55
+ - \`/studio/projects\`: create/select/delete projects (organization-first).
56
+ - \`/studio/{projectSlug}/*\`: project modules (canvas/specs/deploy/integrations/evolution/learning).
57
+ - \`/studio/learning\`: learning hub without selecting a project.
58
+ `
59
+ }];
60
+ registerDocBlocks(tech_studio_workspaces_DocBlocks);
61
+
62
+ //#endregion
@@ -0,0 +1,155 @@
1
+ import { registerDocBlocks } from "../registry.js";
2
+
3
+ //#region ../../libs/contracts/dist/docs/tech/telemetry-ingest.docblock.js
4
+ const tech_telemetry_ingest_DocBlocks = [{
5
+ id: "docs.tech.telemetry.ingest",
6
+ title: "Telemetry Ingest Endpoint",
7
+ summary: "Server-side telemetry ingestion for ContractSpec clients (VS Code extension, CLI, etc.).",
8
+ kind: "reference",
9
+ visibility: "internal",
10
+ route: "/docs/tech/telemetry/ingest",
11
+ tags: [
12
+ "telemetry",
13
+ "api",
14
+ "posthog",
15
+ "analytics"
16
+ ],
17
+ body: `# Telemetry Ingest Endpoint
18
+
19
+ The ContractSpec API provides a telemetry ingest endpoint for clients to send product analytics events.
20
+
21
+ ## Endpoint
22
+
23
+ \`\`\`
24
+ POST /api/telemetry/ingest
25
+ \`\`\`
26
+
27
+ ## Request
28
+
29
+ \`\`\`json
30
+ {
31
+ "event": "contractspec.vscode.command_run",
32
+ "distinct_id": "client-uuid",
33
+ "properties": {
34
+ "command": "validate"
35
+ },
36
+ "timestamp": "2024-01-15T10:30:00.000Z"
37
+ }
38
+ \`\`\`
39
+
40
+ ### Headers
41
+
42
+ | Header | Description |
43
+ |--------|-------------|
44
+ | \`x-contractspec-client-id\` | Optional client identifier (used as fallback for distinct_id) |
45
+ | \`Content-Type\` | Must be \`application/json\` |
46
+
47
+ ### Body
48
+
49
+ | Field | Type | Required | Description |
50
+ |-------|------|----------|-------------|
51
+ | \`event\` | string | Yes | Event name (e.g., \`contractspec.vscode.activated\`) |
52
+ | \`distinct_id\` | string | Yes | Anonymous client identifier |
53
+ | \`properties\` | object | No | Event properties |
54
+ | \`timestamp\` | string | No | ISO 8601 timestamp |
55
+
56
+ ## Response
57
+
58
+ \`\`\`json
59
+ {
60
+ "success": true
61
+ }
62
+ \`\`\`
63
+
64
+ ## Configuration
65
+
66
+ The endpoint requires \`POSTHOG_PROJECT_KEY\` environment variable to be set. If not configured, events are accepted but not forwarded.
67
+
68
+ | Environment Variable | Description | Default |
69
+ |---------------------|-------------|---------|
70
+ | \`POSTHOG_HOST\` | PostHog host URL | \`https://eu.posthog.com\` |
71
+ | \`POSTHOG_PROJECT_KEY\` | PostHog project API key | (required) |
72
+
73
+ ## Privacy
74
+
75
+ - No PII is collected or stored
76
+ - \`distinct_id\` is an anonymous client-generated UUID
77
+ - File paths and source code are never included in events
78
+ - Respects VS Code telemetry settings on the client side
79
+
80
+ ## Events
81
+
82
+ ### Extension Events
83
+
84
+ | Event | Description | Properties |
85
+ |-------|-------------|------------|
86
+ | \`contractspec.vscode.activated\` | Extension activated | \`version\` |
87
+ | \`contractspec.vscode.command_run\` | Command executed | \`command\` |
88
+ | \`contractspec.vscode.mcp_call\` | MCP call made | \`endpoint\`, \`tool\` |
89
+
90
+ ### API Events
91
+
92
+ | Event | Description | Properties |
93
+ |-------|-------------|------------|
94
+ | \`contractspec.api.mcp_request\` | MCP request processed | \`endpoint\`, \`method\`, \`success\`, \`duration_ms\` |
95
+ `
96
+ }, {
97
+ id: "docs.tech.telemetry.hybrid",
98
+ title: "Hybrid Telemetry Model",
99
+ summary: "How ContractSpec clients choose between direct PostHog and API-routed telemetry.",
100
+ kind: "usage",
101
+ visibility: "internal",
102
+ route: "/docs/tech/telemetry/hybrid",
103
+ tags: [
104
+ "telemetry",
105
+ "architecture",
106
+ "posthog"
107
+ ],
108
+ body: `# Hybrid Telemetry Model
109
+
110
+ ContractSpec uses a hybrid telemetry model where clients can send events either directly to PostHog or via the API server.
111
+
112
+ ## Decision Flow
113
+
114
+ \`\`\`
115
+ Is contractspec.api.baseUrl configured?
116
+ ├── Yes → Send via /api/telemetry/ingest
117
+ └── No → Is posthogProjectKey configured?
118
+ ├── Yes → Send directly to PostHog
119
+ └── No → Telemetry disabled
120
+ \`\`\`
121
+
122
+ ## Benefits
123
+
124
+ ### Direct PostHog
125
+ - No server dependency
126
+ - Works offline (with batching)
127
+ - Lower latency
128
+
129
+ ### Via API
130
+ - Centralized key management (no client-side keys)
131
+ - Server-side enrichment and validation
132
+ - Rate limiting and abuse prevention
133
+ - Easier migration to other providers
134
+
135
+ ## Recommendation
136
+
137
+ - **Development**: Use direct PostHog with a dev project key
138
+ - **Production**: Route via API for better governance
139
+
140
+ ## Future: OpenTelemetry
141
+
142
+ The current PostHog implementation is behind a simple interface that can be swapped for OpenTelemetry:
143
+
144
+ \`\`\`typescript
145
+ interface TelemetryClient {
146
+ send(event: TelemetryEvent): Promise<void>;
147
+ }
148
+ \`\`\`
149
+
150
+ This allows future migration without changing client code.
151
+ `
152
+ }];
153
+ registerDocBlocks(tech_telemetry_ingest_DocBlocks);
154
+
155
+ //#endregion