VS Code workflow

VS Code can be the complete working surface for a Srijika application. Desktop Studio is optional: project creation, source editing, architecture checks, the real Vite runtime, and MCP all work without it.

Create and open a project

npm create srijika@latest my-app

When VS Code is detected, the launcher opens the exact generated project folder. On WSL it opens the Windows VS Code application with the matching wsl+<distro> remote target. Creation still succeeds when VS Code or the extension is absent.

To prevent every automatic handoff:

npm create srijika@latest my-app -- --no-open

To open the folder yourself:

code my-app

Always open the complete project folder, not a loose .ui.tsx file. React, TypeScript, tasks, MCP, and ownership detection depend on workspace context.

Inspect the current project Structure Graph

Use the hierarchy icon in the Structure view or run Srijika: Open Current Project Structure Graph. This graph is always available for a configured project; it does not require a React migration session.

The full editor panel starts with App → Features / Shared → Feature → Slot → Part. Expanding an owner reveals its exact UI, Connector, Hook, Store, Logic, API, and Types files. Selecting a file shows directional incoming/outgoing imports, named exports, package dependencies, unresolved imports, capability, and strict architecture findings, with a safe Open file action.

Blue edges remain inside one owner, green edges consume Shared, dashed amber edges cross owners, and red edges/nodes are backed by the shared architecture validator. Search, violations-only filtering, import visibility, collapse, zoom, refresh, and saved panel state are included. The scan uses the same bounded file/byte limits, alias contract, symlink rejection, and diagnostics as the normal architecture check.

For a monorepo, the extension discovers bounded packages that contain their own srijika.config.json. Switch project changes the graph to one package at a time; active-editor context automatically selects the deepest matching package.

Migrate an existing React project

Open the Srijika Activity Bar container and expand Migration, or run Srijika: Open React Migration Dashboard. Choose the immutable React source, then either type/browse a new separate target or select Current workspace target for an eligible empty/resumable target. Current-target mode does not permit in-place conversion of a populated app; the shared engine still rejects overlap and unknown files.

Start/Resume shows the engine inventory, canonical owner architecture, ordered slices, progress, and blockers. Refresh observes the same persisted session after CLI, MCP, Studio, or another agent changes it. The readiness card reports whether Codex is detected and Srijika MCP files are configured, without mislabeling those local facts as an authenticated live connection. Copy Codex handoff prepares the safe one-slice-at-a-time MCP instruction.

Full session JSON opens the complete uncapped machine-readable plan when the compact owner list is not enough.

Inspect the architecture graph

Choose Open Architecture Graph after Start/Resume. A full editor panel shows Application → Feature → Slot → Part and Shared ownership without squeezing the graph into the sidebar. Click any owner to expand its modules and load exact named source exports through bounded immutable slice context. Applied UI/Connector/Hook/Store/API nodes and edges come from read-only inspection of the real converted target; pending work remains marked as planned source. The detail panel lists roles, source and canonical target paths, imports, exports, and linked violations.

Gray means ownership, blue a same-owner import, green a Shared import, and dashed amber a cross-owner dependency that migration must review. Only engine-reported unresolved imports, Srijika diagnostics, architecture/target graph failures, blockers, or failed verification produce a red node. Search, violations-only filtering, import-edge visibility, collapse, zoom, and session refresh are built in.

The webview is not a second source of truth. To place it on the right, enable View → Appearance → Secondary Side Bar, then use the Migration view menu and Move View → Secondary Side Bar. Without the extension, run the complete workflow from the integrated terminal. See React migration.

What the generated workspace includes

.vscode/
├── extensions.json   Srijika Language Support recommendation
├── settings.json     TSX, Emmet, and explicit Srijika fixes
├── tasks.json        Run App, Check Architecture, Build App
└── mcp.json          pinned project MCP server for VS Code
.mcp.json             portable MCP configuration
AGENTS.md              architecture instructions for AI agents

The project remains usable when the extension is not installed. Run the same operations with npx @srijika/cli ... from VS Code’s integrated terminal.

Install Srijika Language Support

Install the public-alpha extension from the Visual Studio Marketplace or search for Srijika Language Support in VS Code’s Extensions view. The stable extension identifier is srijika.srijika-language-support.

For development against a local Srijika Studio checkout:

pnpm --filter srijika-language-support install:local

Then run Developer: Reload Window in VS Code. Generated projects recommend the Marketplace extension automatically; the CLI safely continues with its complete tasks, TypeScript IntelliSense, and MCP workflow if an extension registry is temporarily unavailable.

Use the Structure view

Open the Srijika icon in the Activity Bar and expand Structure. It reads the canonical hierarchy from src/features and the strict owners under src/shared:

Features
└── Home
    ├── slots
    │   └── Navigation
    │       └── parts
    │           └── NavigationItem
    └── owner capabilities
Shared
├── UI
├── Widgets
└── Capabilities

Every Feature, Slot, and Part has an inline + action. The same validated form is available by right-clicking an exact ownership folder in Explorer and choosing Srijika: Add Feature / Slot / Part Capability….

Selected folder	Allowed creation
src/features	New Feature
Feature root	Missing Feature capabilities or New Slot
Slot root	Missing Slot capabilities or New Part
Part root	Missing Part capabilities
src/shared	Shared UI, Shared Widget, or Shared Headless Capability

For a new owner, enter one PascalCase name and choose only capabilities valid for that owner. UI + Connector are required for Feature, Slot, Part, and Shared Widget; Shared UI has no runtime layer, while Shared Headless Capability has no UI or Connector and requires at least one runtime layer. The form shows every exact path before writing and refuses arbitrary locations, duplicates, and overwrites.

For an existing owner, created files are shown as disabled Created entries. Choose one missing capability or Select all missing files to create and safely rewire them as one batch.

When the canonical Hook or Store already exists, the form also offers Add private Hook / Store behavior. Enter only a PascalCase suffix such as Keyboard or Filters. VS Code derives useOwnerKeyboard.ts or ownerFilters.store.ts; if the gateway is still flat, the same atomic edit moves it into hooks/ or stores/, updates project imports, and deletes the root copy. Mixed layouts, custom names, index.ts, and deeper capability folders are architecture errors.

For shared creation, the same form offers only three composite choices:

• Shared UI Primitive — required pure UI, optional Types, no runtime files;
• Shared Widget — required UI + Connector, optional Hook/Store/Logic/API/Types;
• Shared Headless Capability — no UI/Connector and at least one runtime layer.

Examples include Button in shared/ui, UserMenu in shared/widgets, and Auth or a common HTTP boundary in shared/capabilities. The extension derives every path and refuses freehand utils, common, barrels, Feature imports from shared, and private shared imports from consumers. Expanded Hook/Store behavior uses the same safe move and project-wide import rewrite as Feature owners.

Edit UI with shared language intelligence

Srijika Language Support validates every file ending in the resolved UI suffix (canonical default .ui.tsx) on open, change, and save using the same restricted compiler as Studio. It adds:

• editor diagnostics and exact source ranges;
• compiler-owned Quick Fixes;
• supported intrinsic elements after typing <;
• supported props and event bindings inside JSX opening tags; and
• project-wide Feature → Slot → Part architecture diagnostics.

The project check also enforces the same hard source boundaries as CLI, Studio, and MCP:

• SRIJIKA4116 / SRIJIKA-ARCH-DIRECT-CHILD-UI: only the matching Connector renders an owner UI; parent/sibling composition uses the child Connector, with pure Shared UI Primitive composition as the only cross-owner UI exception;
• SRIJIKA4117 / SRIJIKA-ARCH-PASSIVE-TYPES: *.types.ts contains passive interfaces/type aliases only and every consumer uses import type or export type; and
• every UI rejects identifier/property Hooks (useOwner(), React.useState()) and browser/runtime APIs (fetch, XMLHttpRequest, WebSocket, localStorage, sessionStorage) with SRIJIKA4101 / SRIJIKA-ARCH-UI-RUNTIME-IMPORT; external state/router/request/query lifecycle and callable utility behavior is also blocked, while types, styles/assets, safe React JSX support, and JSX-only presentational bindings remain valid; and
• SRIJIKA4118 / SRIJIKA-ARCH-LOGIC-RUNTIME-CONCERN: Logic keeps pure validation, authorization, transforms, aggregation, and API orchestration, but React/query/router/client-state lifecycle moves to Hook, Connector, or Store and request transport stays in API.
• SRIJIKA4119 / SRIJIKA-ARCH-UNPROVABLE-DYNAMIC-IMPORT: computed import()/require() targets are forbidden inside governed roots.
• SRIJIKA4120 / SRIJIKA-ARCH-UNRESOLVED-PROJECT-ALIAS: declared/reserved project aliases must resolve to scanned governed source.
• SRIJIKA4121 / SRIJIKA-ARCH-UNRESOLVED-PROJECT-IMPORT: governed relative and src/... source imports must resolve inside the configured ownership roots; CSS/static assets are exempt.

It also rejects freehand Shared paths, noncanonical owner spellings, and Shared runtime dependency cycles. Type-only Shared edges remain valid.

VS Code’s built-in TypeScript service remains responsible for ordinary React, JSX, imports, navigation, and IntelliSense. Srijika adds only its stricter source and ownership contract.

Run Srijika: Check Current UI File for the active source or Srijika: Check Feature Architecture for the whole workspace.

The extension resolves any custom architecture roots, Slot/Part/Hook/Store directory names, and canonical suffixes from srijika.config.json through the same validator as CLI. Roots must remain bounded, project-relative, and non-overlapping; directory names and suffixes must remain case-insensitively distinct and basename-safe; suffixes cannot end with one another. Traversal, absolute paths, backslashes, duplicate names, and symlink escapes fail before discovery or creation.

If architecture is absent, VS Code uses canonical defaults. If it is present, the exact feature-slot-part-v1 profile is required; missing or unsupported profiles fail closed instead of showing a default-root Structure tree. The Exact files and safe rewiring list is returned by the canonical planner with the resolved config—including custom roots, directory names, suffixes, moves, and rewires. The webview never reconstructs paths while the user types.

The project contract also requires sourceOfTruth: "tsx" and a bounded entry ending in the configured UI suffix. That entry is strict and counted even outside ownership roots. All twelve architecture override fields are shared with CLI, Studio, and MCP. Root tsconfig.json is parsed as JSONC: extends is rejected, references must be absent or empty, compilerOptions.baseUrl must be omitted, and only exact/slash-delimited terminal /* paths count. Vite-only aliases are unsupported until mirrored there. Reads and full-project migration rewires fail closed at 4,096 sources, 32,768 entries, 4,096 directories, depth 32, 4 MiB per source, and 24 MiB total (with 64 KiB project config and 1 MiB tsconfig.json caps).

Create behavior without layer jumps

The Structure form and context menu create the same progressive chain as the CLI:

UI ← Connector → Hook → Store → Logic → API → Types

The Connector calls the highest available layer. If Hook exists, it cannot jump to Store, Logic, or API. Child-private modules stay below their owner; shared sibling behavior is promoted to the nearest common Part, Slot, Feature, or src/shared owner.

Promotion and split guidance is emitted as structured evidence: SRIJIKA-ARCH-RECOMMEND-PROMOTE-OWNER accompanies the blocking ownership error when a private runtime capability crosses an owner boundary, while SRIJIKA-ARCH-RECOMMEND-SPLIT-OWNER appears as non-blocking SRIJIKA4202 only at 201 UI-function lines, 301 UI-file lines, or 17 contract members.

Read Project anatomy for the complete ownership rules.

Run the real application

The Structure title bar provides Run App, Stop App, and Doctor.

• Run App starts the project’s real strict-port Vite server.
• Stop App terminates the managed VS Code task.
• Doctor checks Node, optional Bun, package manager, lockfile, and scripts.

You can run the generated tasks without the extension from Terminal → Run Task:

• Srijika: Run App
• Srijika: Check Architecture
• Srijika: Build App

The runtime default is Node. To request Bun for a detected Vite project, set:

{
  "srijika.runtime": "bun",
  "srijika.devPort": 5173
}

Changing runtime never changes the project’s package manager or lockfile.

Connect Codex or another MCP client

Generated .vscode/mcp.json starts the pinned @srijika/[email protected] process with ${workspaceFolder} as the project. The MCP server can inspect, validate, preview scaffold plans, and atomically apply approved Feature/Slot/Part and shared-owner structure without Desktop Studio.

Studio-only visual bridge tools appear only when Studio is running and authenticated. Code-project tools do not depend on that bridge.

Read MCP without Desktop Studio for the portable configuration and manual launch command.

Command Palette reference

• Srijika: Check Current UI File
• Srijika: Check Feature Architecture
• Srijika: Open Setup and Language Support Guide
• Srijika: Add Feature / Slot / Part Capability…
• Srijika: Refresh Structure
• Srijika: Run App
• Srijika: Stop App
• Srijika: Install / Sync Dependencies
• Srijika: Run Doctor

Troubleshooting

Structure is empty

Open the project root containing src/features, then run Srijika: Refresh Structure. A loose file or parent directory is not a valid ownership root.

React JSX types are missing

Finish dependency installation and run Developer: Reload Window. Errors for react/jsx-runtime or JSX.IntrinsicElements indicate an incomplete or stale React workspace, not a Srijika element restriction.

npx @srijika/cli install

Run App reports port 5173 in use

Stop the existing Vite process or change srijika.devPort to a known free port. Srijika uses a strict port and does not silently move the application.

Extension is unavailable

Continue with the generated tasks and terminal commands:

npx @srijika/cli check --watch
npx @srijika/cli dev

The project format does not depend on the extension.

CLI-first workflow

Create, run, validate, and scaffold the same project from any terminal.

Project anatomy

Understand Feature, Slot, Part, ownership, promotion, and the progressive chain.

Open the CLI guide

Read project anatomy