@taiga-ai/mcp-server 0.2.3-dev.224 → 0.2.3-dev.226

package/dist/index.js

@@ -4,22 +4,237 @@ import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"
 import { z } from "zod";
 //#region ../../packages/feature-flags/dist/index.js
 /**
-* Resolve the full flag set for an environment. THE single place the
-* per-environment rules live. Frozen so a resolved set cannot be mutated at
-* runtime — changing a flag is a source edit here, not an assignment in an app.
+* Feature flags shared across web, api, mcp-server, and the documentation site.
+*
+* {@link featureFlagDefinitions} is the single source of truth for WHICH flags
+* exist, HOW each one resolves per environment, and what it is for; the
+* {@link FeatureFlags} type is derived from it. Every app calls
+* {@link resolveFeatureFlags} with its own environment identifier so a feature
+* is shown or hidden consistently everywhere from one rule set:
+*   - web: `resolveFeatureFlags(config.VITE_APP_ENV)` (baked at build time)
+*   - api: a fail-safe wrapper (`apps/api/src/shared/config/feature-flags.ts`)
+*     that resolves `ENVIRONMENT` and defaults to `prod` for any unrecognized
+*     value when deployed, so a WIP feature is never leaked
+*   - docs: `apps/docs/src/content.config.ts` resolves flags for the
+*     environment being built and DROPS pages carrying `flag: <name>` where
+*     that flag is off, so docs.tai.ga never describes a feature customers
+*     cannot see (PRO-1033)
+*
+* Flags are boot-time constants — no remote source. Changing a rule here
+* re-derives the flag everywhere.
+*
+* ## Adding a flag
+*
+* One entry in {@link featureFlagDefinitions}: its `availability`, a one-line
+* `description` for the web dev panel, and the full account of what it gates
+* and why as the JSDoc above the entry. If the flag is OFF in prod, two more
+* things follow, and the first will stop you:
+*
+* 1. **`make docs-check-claims` fails until the flag is registered** in
+*    `FLAG_PHRASES` (`apps/docs/scripts/check-claims.py`). That is deliberate:
+*    the check used to iterate its own dict, so an unregistered flag was never
+*    examined and a page could describe an invisible feature. Register the
+*    words a page would use for the feature, or `[]` if it has a page of its
+*    own that declares the flag.
+* 2. **A page for the feature can be written now**, carrying `flag: <name>` in
+*    its frontmatter. It is published on dev and staging and excluded from
+*    prod, and it publishes by itself when the flag graduates — no docs change.
+*    See the `flag:` section in `apps/docs/AGENTS.md`, which also covers the
+*    one constraint: nothing published may link to a flagged page.
+*/
+/**
+* THE registry: one entry per flag. Adding a flag is adding an entry here;
+* {@link FeatureFlags} and {@link resolveFeatureFlags} derive from it.
+*/
+const featureFlagDefinitions = Object.freeze({
+	/**
+	* Skills feature. When `false` the feature is fully dormant:
+	*   - web: nav groups, dashboard governance row, and skills routes are hidden
+	*   - api: the `/v1/agent-skills*` endpoints are not registered
+	*   - mcp: the skill tools, their instruction mentions, and the
+	*     `getProjectContext` skills summary are omitted
+	*   - agent runtime: no skills are injected into agent prompts
+	*   - seeding: no default skills are created for new tenants/teams/projects
+	*
+	* Hidden for now (not needed in the product yet; may return later).
+	*/
+	skills: {
+		description: "Agent skills: the skills routes and pages, the MCP skill tools, and skills injected into agent prompts. Hidden in every environment for now.",
+		availability: "nowhere"
+	},
+	/**
+	* Insights surface (Learn loop) — production feedback and customer signals
+	* feeding the next iteration.
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod. Surfaces the
+	* scaffold page in lower environments only while the feature is designed.
+	* **Remove this flag (and its gates) at GA.**
+	*/
+	insights: {
+		description: "Insights section of the Learn loop: production feedback and customer signals feeding the next iteration.",
+		availability: "non-prod"
+	},
+	/**
+	* UI Sparring (PRO-630) — AI-generated UI concepts for the CUSTOMER's app,
+	* rendered client-side in a sandboxed iframe styled with the tenant's
+	* design_standards tokens. When `false` the feature is fully dormant:
+	*   - web: the concept gallery, the Studio and the `/dev/ui-artifact-test`
+	*     route are not registered
+	*   - api: the `/v1/projects/:projectId/ui-artifacts/*` endpoints are not
+	*     registered
+	*
+	* The flow surface moved out from under this flag in PRO-1029 — see
+	* {@link FeatureFlags.flowStudio}.
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod while the feature is
+	* built out (foundation slice → workshop → binding).
+	* **Remove this flag (and its gates) at GA.**
+	*/
+	uiSparring: {
+		description: "UI Sparring: AI-generated UI concepts for the customer's application, the concept gallery and the UI Studio, with their API endpoints.",
+		availability: "non-prod"
+	},
+	/**
+	* User Flow Studio (PRO-1029) — the conversational surface for the
+	* `user_flow` document: talk the flows into shape, the ux-planning agent
+	* drafts and revises them, every agreed change lands in the document.
+	*
+	* Split out of {@link FeatureFlags.uiSparring} because working out user flows
+	* is Discovery work that stands on its own: it happens before anyone asks
+	* what a screen looks like, and it is useful to a customer who never opens
+	* the UI Studio. Sharing one flag meant flows could not ship without shipping
+	* concept generation and the sparring chat with them.
+	*
+	* Gates the web surface only — the route and the Edit control on the user
+	* flows document. The streaming endpoint (`POST
+	* /v1/conversations/:id/workshop-stream`) is deliberately NOT gated: it
+	* carries a conversation, the same as the spec-chat route beside it, and
+	* hiding a page is not a reason to make an authenticated, capability-checked
+	* endpoint conditional.
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod until the surface has
+	* proven itself there. **Remove this flag (and its gates) at GA.**
+	*/
+	flowStudio: {
+		description: "User Flow Studio: the conversational surface where the ux-planning agent drafts and revises the user flows document.",
+		availability: "non-prod"
+	},
+	/**
+	* Customer-definable check-and-stamp checklists (PRO-946..948, design
+	* PRO-933). When `false` the feature is fully dormant:
+	*   - api: the `/v1/checklist-*` endpoints are not registered
+	*   - api: no checklist instances are created on project creation (PR 2/3)
+	*   - web: no discovery-pipeline checklist step, no org-settings editor
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod while the three
+	* slices (schema/API → gate + project surface → template editor) land.
+	* **Remove this flag (and its gates) at GA.**
+	*/
+	checklists: {
+		description: "Customer-defined check-and-stamp checklists: the discovery pipeline step, the organization settings editor and their API endpoints.",
+		availability: "non-prod"
+	},
+	/**
+	* Factory v2 engineer pod (PRO-1313..1315): the admin-only `/v1/engineer/*`
+	* endpoints that trigger the EC2-backed Runtime Instances probe runtime.
+	* When `false` the routes are not registered, so nothing in the product can
+	* reach that runtime. This flag NEVER re-routes real work: the existing
+	* planning and coding agents remain the only dispatch path in every
+	* environment. OFF in prod until the real engineer pod ships behind its
+	* own, separate rollout decision.
+	*/
+	engineerPod: {
+		description: "Factory v2 engineer pod: the admin-only /v1/engineer endpoints that trigger the Runtime Instances probe runtime (dev/staging only).",
+		availability: "non-prod"
+	},
+	/**
+	* Questionnaire filling (PRO-932) — a customer uploads their own requirement
+	* spreadsheet, Taiga answers what the project's evidence supports with
+	* `document@version` citations, a human attests, and the answers are written
+	* back into that same workbook. ASTORI's THL Liite 4 is the first named
+	* preset, not a modelled regulation.
+	*
+	* When `false` the feature is fully dormant:
+	*   - api: the `/v1/questionnaires*` and `/v1/projects/:id/questionnaires`
+	*     endpoints are not registered
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod while the slices
+	* (import → fill → attest + export) land.
+	* **Remove this flag (and its gates) at GA.**
+	*/
+	questionnaires: {
+		description: "Questionnaire filling: answer an uploaded requirement spreadsheet from project evidence with citations, attest, and write the answers back.",
+		availability: "non-prod"
+	},
+	/**
+	* UI Studio Wizard (PRO-1030) — the guided three-choice route through the UI
+	* decisions, for the person finishing Discovery who does not want a
+	* workbench. When `false` the feature is fully dormant:
+	*   - web: the `/ui-wizard` route is not registered, and Discovery's UI
+	*     Studio card offers only the studio itself
+	*
+	* Split out of {@link FeatureFlags.uiSparring} rather than riding it, for the
+	* reason {@link FeatureFlags.flowStudio} was: the wizard and the studio are
+	* two front doors onto the same concepts, and they will not graduate on the
+	* same day. Everything the wizard reaches is gated on `uiSparring` server-side
+	* (the concept job's own assembler throws without it), so every gate on this
+	* flag ANDs the two — a wizard released alone would offer a button that 500s.
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod.
+	* **Remove this flag (and its gates) at GA.**
+	*/
+	uiStudioWizard: {
+		description: "UI Studio Wizard: the guided three-choice route through the UI decisions. Only works when uiSparring is also on, including on the API.",
+		availability: "non-prod"
+	},
+	/**
+	* Design-system emitter (PRO-887): materialise an organisation's INTERNAL
+	* Design Standards into `src/styles/design-tokens.css` + `DESIGN.md` in the
+	* generated application at build bootstrap. Never active for a tenant with a
+	* linked design-system repository (that repo is the source of truth).
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod until the first
+	* internal-DS build has been verified end to end.
+	*/
+	designEmitter: {
+		description: "Design-system emitter: writes an organization's internal design standards into design-tokens.css and DESIGN.md in the generated application at build bootstrap.",
+		availability: "non-prod"
+	},
+	/**
+	* Autonomous merge (project "Autonomous Merge") -- Taiga decides when an
+	* agent-authored pull request merges, under a customer-set autonomy policy,
+	* instead of parking every green PR at `needs_review` for a person.
+	*
+	* NOT the customer's switch, and the distinction is the whole reason this
+	* comment is long. THIS flag is a per-ENVIRONMENT constant answering "does
+	* the capability exist in this build at all". The customer's consent is a
+	* separate per-TENANT policy resolved across org -> team -> project ->
+	* initiative, where org defaults to off. Reading this flag as "the tenant
+	* enabled auto-merge" would merge into a repository whose owner never asked
+	* for it. One is the kill switch, the other is the consent; they are never
+	* interchangeable.
+	*
+	* Release toggle: ON in local/dev/staging, OFF in prod while the policy core,
+	* forge preflight, executor and safety net land.
+	* **Remove this flag (and its gates) at GA.**
+	*/
+	autoMerge: {
+		description: "Autonomous merge: Taiga merges green agent-authored pull requests under the customer's autonomy policy. This is the capability kill switch, not the tenant's consent.",
+		availability: "everywhere"
+	}
+});
+/** Every flag name, in registry order. */
+const featureFlagNames = Object.keys(featureFlagDefinitions);
+/**
+* Resolve the full flag set for an environment from the registry. Frozen so a
+* resolved set cannot be mutated at runtime — changing a flag is a source edit
+* in {@link featureFlagDefinitions}, not an assignment in an app.
 */
 function resolveFeatureFlags(env) {
-	return Object.freeze({
-		skills: false,
-		insights: env !== "prod",
-		uiSparring: env !== "prod",
-		flowStudio: env !== "prod",
-		checklists: env !== "prod",
-		questionnaires: env !== "prod",
-		uiStudioWizard: env !== "prod",
-		designEmitter: env !== "prod",
-		autoMerge: true
-	});
+	const isOn = (availability) => availability === "everywhere" || availability === "non-prod" && env !== "prod";
+	const resolved = {};
+	for (const name of featureFlagNames) resolved[name] = isOn(featureFlagDefinitions[name].availability);
+	return Object.freeze(resolved);
 }
 /**
 * Safe-default snapshot, resolved as `prod`: every still-gated release toggle

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@taiga-ai/mcp-server",
-  "version": "0.2.3-dev.224",
+  "version": "0.2.3-dev.226",
   "description": "MCP server for Taiga -- gives AI assistants access to documents, skills, and projects",
   "type": "module",
   "main": "./dist/index.js",