fabric-vibecoding-settings 0.1__tar.gz

fabric_vibecoding_settings-0.1/.gitignore

@@ -0,0 +1,59 @@
+# Environment and local machine state
+.env
+.env.*
+!.env.example
+*.local.json
+!profiles/claude/settings.local.json
+!cli/profiles/claude/settings.local.json
+
+# Local Claude Code overrides
+.claude/settings.local.json
+
+# Data and generated runtime artifacts do not belong in this source package
+logs/
+src/
+!cli/src/
+fabric_notebooks/
+_delta_log/
+*.checkpoint.parquet
+*.parquet
+*.csv
+*.xlsx
+*.xls
+!tool/data/
+!tool/data/mock-data-generator.py
+
+# Allow packaged target scaffolding placeholders under profiles/shared/scaffold
+!profiles/shared/scaffold/data/
+!profiles/shared/scaffold/data/sandbox/
+!profiles/shared/scaffold/data/sandbox/.gitkeep
+!profiles/shared/scaffold/workspace/
+!profiles/shared/scaffold/workspace/.gitkeep
+
+# Folder-redesign baseline snapshot (Step 0)
+baseline-snapshot/
+
+# Python
+__pycache__/
+*.pyc
+*.pyo
+*.pyd
+.Python
+*.egg-info/
+dist/
+.venv/
+venv/
+
+# Memory — runtime memory is persisted via the graph MCP CRUD ops
+memory/*.md
+
+# Knowledge graph build artifacts (rebuilt by server/builders/build-graph.py)
+dist/.graph/
+
+# OS / IDE
+.DS_Store
+Thumbs.db
+.vscode/
+.idea/
+*.swp
+.pytest_cache/

fabric_vibecoding_settings-0.1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Silvio Cardoso
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

fabric_vibecoding_settings-0.1/PKG-INFO

@@ -0,0 +1,219 @@
+Metadata-Version: 2.4
+Name: fabric-vibecoding-settings
+Version: 0.1
+Summary: Install Microsoft Fabric agent profiles (Claude Code and Codex) into a target repository.
+License: MIT
+License-File: LICENSE
+Requires-Python: >=3.10
+Requires-Dist: rich>=13.7
+Requires-Dist: typer>=0.12
+Provides-Extra: graph
+Requires-Dist: networkx>=3.2; extra == 'graph'
+Requires-Dist: rank-bm25>=0.2.2; extra == 'graph'
+Provides-Extra: server
+Requires-Dist: mcp>=1.0; extra == 'server'
+Requires-Dist: networkx>=3.2; extra == 'server'
+Requires-Dist: pydantic>=2.7; extra == 'server'
+Requires-Dist: rank-bm25>=0.2.2; extra == 'server'
+Requires-Dist: uvicorn>=0.30; extra == 'server'
+Description-Content-Type: text/markdown
+
+# Fabric Agent Pack
+
+Vendor-native **Codex** and **Claude Code** profiles for Microsoft Fabric data engineering.
+
+Fabric Agent Pack turns a normal git repository into a guided Microsoft Fabric project workspace. It installs agent instructions and lightweight scaffold files, while `fabric-vibe` provides the setup, validation, notebook, pipeline, lakehouse, and workspace helpers from the package.
+
+> This repository is the **source package and installer**, not the day-to-day Fabric project workspace. Install a profile into your actual project repository, then run Codex or Claude Code from that target repository root.
+
+**Overview**
+
+![Fabric Agent Pack](img/overview.png)
+
+## Quick start
+
+The CLI is published as `fabric-vibecoding-settings` on PyPI. Installing it puts two console scripts on your PATH:
+
+| Command | Role |
+|---|---|
+| `fabric-vibecoding-agents` | Install / check / refresh agent profiles in a project repo |
+| `fabric-vibe` | Daily Fabric helpers run from a project repo (notebook, pipeline, lakehouse, workspace, lint, precommit) |
+
+### Step 1 — Install the CLI
+
+```bash
+uv tool install fabric-vibecoding-settings        # recommended
+# or
+pip install fabric-vibecoding-settings
+```
+
+
+### Step 2 — Install a profile into your project repo
+
+```bash
+# preview
+fabric-vibecoding-agents install --profile claude --target /path/to/project-repo --dry-run
+
+# apply (also runs fabric-vibe setup: ms-fabric-cli + creds + workspaces.json)
+fabric-vibecoding-agents install --profile claude --target /path/to/project-repo
+
+# verify drift later
+fabric-vibecoding-agents check --profile claude --target /path/to/project-repo
+```
+
+`fabric-vibecoding-agents install` copies the profile and scaffold files into the target, then runs `fabric-vibe setup` from the target root to install `ms-fabric-cli`, prompt for `FABRIC_TENANT_ID` / `CLIENT_ID` / `CLIENT_SECRET`, verify auth, and populate `workspaces.json`. Pass `--no-bootstrap` to skip.
+
+### Step 3 — Daily work inside the project
+
+Once a profile is installed, run the daily helpers via `fabric-vibe` from the project root:
+
+```bash
+fabric-vibe notebook build  <name>
+fabric-vibe notebook deploy <name> <workspace_id>
+fabric-vibe pipeline manage list
+fabric-vibe lakehouse list-tables
+fabric-vibe workspace switch <displayName>
+fabric-vibe lint
+fabric-vibe precommit
+```
+
+Each subcommand passes its trailing argv through to package-bundled helpers while preserving the target repo as the working directory. Use `fabric-vibe <group> --help` to see what each helper accepts.
+
+### `fabric-vibecoding-agents` flags
+
+| Flag | Effect |
+|---|---|
+| `--profile {codex,claude,all}` / `-p` | Pick the agent profile (required) |
+| `--target <path>` / `-t` | Target git repository (required) |
+| `--dry-run` | Preview changes without writing (install/refresh only) |
+| `--force` | Overwrite non-managed existing files |
+| `--backup` | Back up replaced files alongside the originals |
+| `--no-bootstrap` | Copy files only; skip the post-install Fabric auth + workspaces.json bootstrap (install only) |
+| `--verbose` / `-v` | Debug-level logging |
+| `--quiet` / `-q` | Suppress info logging |
+| `--help` / `-h` | Show usage |
+
+### Service-principal credentials
+
+Minimum Fabric workspace role: **Contributor**. The bootstrap prompts for these and stores them safely:
+
+| Prompt | Stored where |
+|---|---|
+| `FABRIC_TENANT_ID` | `<target>/.env` |
+| `FABRIC_CLIENT_ID` | `<target>/.env` |
+| `FABRIC_CLIENT_SECRET` | OS environment only — never `.env` |
+
+On Windows the secret is written to the user registry via `SetEnvironmentVariable("User")`. On Linux/macOS it is appended to your shell profile (`~/.zprofile`, `~/.bash_profile`, or `~/.profile`).
+
+Create the service principal once, before running setup:
+
+```text
+Azure Portal → App registrations → New registration
+  Name: fabric-agent-<project>
+  Supported account types: this tenant only
+
+Fabric workspace → Manage access → Add → service principal
+  Role: Contributor
+```
+
+Re-running the same install command is idempotent — credentials already set are skipped, and managed files only change when their source content changes. If you need to bootstrap again later (e.g. after rotating the secret), run `fabric-vibe setup` from inside the target.
+
+## Docker image
+
+The Fabric MCP server is also published as a Docker image on Docker Hub:
+
+```bash
+docker pull silviocardoso/fabric-vibecoding-mcp-server:latest
+```
+
+Image page: [silviocardoso/fabric-vibecoding-mcp-server](https://hub.docker.com/r/silviocardoso/fabric-vibecoding-mcp-server)
+
+The image builds from `server/Dockerfile` and includes the server-side MCP tools plus the baked knowledge-graph artifacts. Use it when you want to run the MCP server from a published image instead of building it locally with `docker compose up --build`.
+
+Minimal `docker-compose.yml` using the published image:
+
+```yaml
+services:
+  server:
+    image: silviocardoso/fabric-vibecoding-mcp-server:latest
+    container_name: fabric-mcp-server
+    environment:
+      PORT: "8000"
+      HOST: "0.0.0.0"
+      LOG_LEVEL: ${LOG_LEVEL:-info}
+    ports:
+      - "127.0.0.1:8000:8000"
+    restart: unless-stopped
+```
+
+Then start it with:
+
+```bash
+docker compose up
+```
+
+This binds the server to `127.0.0.1:8000`, so it is reachable from your machine without exposing it to the LAN.
+
+
+## Learn more
+
+- [docs/workflow.md](docs/workflow.md) — agent → skill → tool → Fabric flow, focused on what you get in the target repo.
+- [docs/knowledge-graph.md](docs/knowledge-graph.md) — what's indexed under `memory/` and the `graph_*` MCP surface the agents call.
+- [docs/architecture.md](docs/architecture.md) — full source-vs-target picture: MCP servers, folder layout, setup CLI, and the redesign migration notes.
+
+
+## Example result
+
+The screenshots below show an end-to-end bronze ingestion of EU day-ahead electricity prices into a Fabric Lakehouse.
+
+**1 — Authoring the bronze notebook**
+
+The developer agent authors `bronze_electricity_day_ahead_prices.py` while the upstream `download_sources` job runs in Fabric.
+
+![Claude Code authoring the bronze notebook source file alongside the Fabric Monitor showing download_sources in progress](img/fabric-0.png)
+
+**2 — Deploying and triggering**
+
+Codex reads the workspace ID from `.env`, deploys the notebook through the Fabric REST API, and triggers the run.
+
+![Codex terminal deploying the notebook while the Fabric Monitor shows the job queued](img/fabric-1.png)
+
+**3 — Full run history**
+
+The Fabric Monitor shows `download_sources` → `bronze_electricity_day_ahead_prices` → `dq_bronze_electricity_day_ahead_prices` succeeding after schema-contract iterations.
+
+![Fabric Monitor showing the full activity history with final succeeded runs and earlier failed DQ iterations](img/fabric-2.png)
+
+**4 — Ingested Delta table**
+
+The resulting Delta table contains 1,000 rows and 27 columns, including lineage envelope fields such as `_ingest_timestamp`, `_source_system`, and `_batch_id`.
+
+![Fabric Lakehouse table view showing the ingested bronze_electricity_day_ahead_prices Delta table with 1000 rows](img/fabric-3.png)
+
+
+**5 — Restricted workspace for AI agentic development**
+
+The agent runs in a dedicated workspace. Permissions are set at the workspace level to ensure there is no access to production data or pipelines.
+
+![Fabric Workspace permissions](img/fabric-4.png)
+
+**6 — Development Lifecycle**
+
+The code is integrated with Git, and the agent develops everything in a dedicated feature branch. Human developers can review the pull request later and merge the work from the feature branch into dev.
+
+![Agent Feature branch](img/fabric-5.png)
+
+> **Note**: The VIBECODING workspace was set up by selecting individual Fabric items. This narrowed down the codebase to only the scripts that stakeholders actually care about.
+
+## Live reference implementation
+
+[**fabric-open-data-lu**](https://github.com/scardoso-lu/fabric-open-data-lu) is a public target repository with Claude- and Codex-generated scripts for EU open-data ingestion into Microsoft Fabric. It demonstrates the `download_` → `bronze_` → `dq_bronze_` notebook pattern used by this package.
+
+## Why use it?
+
+- **Ship faster** — agents handle notebook authoring, deployment, schema validation, and pipeline wiring. Engineers own approvals and production handoffs.
+- **OWASP-compliant by default** — Data Security Top 10 and Supply Chain (A03:2025) baked in: no credential leakage, parameterized queries, pinned dependencies, CVE checks, PII masking.
+- **Harness engineering** — agents run inside a structured harness of guardrails, role definitions, skill boundaries, and memory. Consistent, auditable behavior without custom prompt engineering per project.
+- **Separation of duties** — implementation, testing, and security review are distinct agents. Nothing reaches production without a human sign-off.
+- **Quality gates at every layer** — mandatory Great Expectations checks at bronze, silver, and gold. Failed DQ stops the pipeline; agents do not auto-retry.
+- **Token savings** — RTK optimizer cuts shell-output tokens 60–90%, keeping long sessions economical.

fabric_vibecoding_settings-0.1/README.md

@@ -0,0 +1,199 @@
+# Fabric Agent Pack
+
+Vendor-native **Codex** and **Claude Code** profiles for Microsoft Fabric data engineering.
+
+Fabric Agent Pack turns a normal git repository into a guided Microsoft Fabric project workspace. It installs agent instructions and lightweight scaffold files, while `fabric-vibe` provides the setup, validation, notebook, pipeline, lakehouse, and workspace helpers from the package.
+
+> This repository is the **source package and installer**, not the day-to-day Fabric project workspace. Install a profile into your actual project repository, then run Codex or Claude Code from that target repository root.
+
+**Overview**
+
+![Fabric Agent Pack](img/overview.png)
+
+## Quick start
+
+The CLI is published as `fabric-vibecoding-settings` on PyPI. Installing it puts two console scripts on your PATH:
+
+| Command | Role |
+|---|---|
+| `fabric-vibecoding-agents` | Install / check / refresh agent profiles in a project repo |
+| `fabric-vibe` | Daily Fabric helpers run from a project repo (notebook, pipeline, lakehouse, workspace, lint, precommit) |
+
+### Step 1 — Install the CLI
+
+```bash
+uv tool install fabric-vibecoding-settings        # recommended
+# or
+pip install fabric-vibecoding-settings
+```
+
+
+### Step 2 — Install a profile into your project repo
+
+```bash
+# preview
+fabric-vibecoding-agents install --profile claude --target /path/to/project-repo --dry-run
+
+# apply (also runs fabric-vibe setup: ms-fabric-cli + creds + workspaces.json)
+fabric-vibecoding-agents install --profile claude --target /path/to/project-repo
+
+# verify drift later
+fabric-vibecoding-agents check --profile claude --target /path/to/project-repo
+```
+
+`fabric-vibecoding-agents install` copies the profile and scaffold files into the target, then runs `fabric-vibe setup` from the target root to install `ms-fabric-cli`, prompt for `FABRIC_TENANT_ID` / `CLIENT_ID` / `CLIENT_SECRET`, verify auth, and populate `workspaces.json`. Pass `--no-bootstrap` to skip.
+
+### Step 3 — Daily work inside the project
+
+Once a profile is installed, run the daily helpers via `fabric-vibe` from the project root:
+
+```bash
+fabric-vibe notebook build  <name>
+fabric-vibe notebook deploy <name> <workspace_id>
+fabric-vibe pipeline manage list
+fabric-vibe lakehouse list-tables
+fabric-vibe workspace switch <displayName>
+fabric-vibe lint
+fabric-vibe precommit
+```
+
+Each subcommand passes its trailing argv through to package-bundled helpers while preserving the target repo as the working directory. Use `fabric-vibe <group> --help` to see what each helper accepts.
+
+### `fabric-vibecoding-agents` flags
+
+| Flag | Effect |
+|---|---|
+| `--profile {codex,claude,all}` / `-p` | Pick the agent profile (required) |
+| `--target <path>` / `-t` | Target git repository (required) |
+| `--dry-run` | Preview changes without writing (install/refresh only) |
+| `--force` | Overwrite non-managed existing files |
+| `--backup` | Back up replaced files alongside the originals |
+| `--no-bootstrap` | Copy files only; skip the post-install Fabric auth + workspaces.json bootstrap (install only) |
+| `--verbose` / `-v` | Debug-level logging |
+| `--quiet` / `-q` | Suppress info logging |
+| `--help` / `-h` | Show usage |
+
+### Service-principal credentials
+
+Minimum Fabric workspace role: **Contributor**. The bootstrap prompts for these and stores them safely:
+
+| Prompt | Stored where |
+|---|---|
+| `FABRIC_TENANT_ID` | `<target>/.env` |
+| `FABRIC_CLIENT_ID` | `<target>/.env` |
+| `FABRIC_CLIENT_SECRET` | OS environment only — never `.env` |
+
+On Windows the secret is written to the user registry via `SetEnvironmentVariable("User")`. On Linux/macOS it is appended to your shell profile (`~/.zprofile`, `~/.bash_profile`, or `~/.profile`).
+
+Create the service principal once, before running setup:
+
+```text
+Azure Portal → App registrations → New registration
+  Name: fabric-agent-<project>
+  Supported account types: this tenant only
+
+Fabric workspace → Manage access → Add → service principal
+  Role: Contributor
+```
+
+Re-running the same install command is idempotent — credentials already set are skipped, and managed files only change when their source content changes. If you need to bootstrap again later (e.g. after rotating the secret), run `fabric-vibe setup` from inside the target.
+
+## Docker image
+
+The Fabric MCP server is also published as a Docker image on Docker Hub:
+
+```bash
+docker pull silviocardoso/fabric-vibecoding-mcp-server:latest
+```
+
+Image page: [silviocardoso/fabric-vibecoding-mcp-server](https://hub.docker.com/r/silviocardoso/fabric-vibecoding-mcp-server)
+
+The image builds from `server/Dockerfile` and includes the server-side MCP tools plus the baked knowledge-graph artifacts. Use it when you want to run the MCP server from a published image instead of building it locally with `docker compose up --build`.
+
+Minimal `docker-compose.yml` using the published image:
+
+```yaml
+services:
+  server:
+    image: silviocardoso/fabric-vibecoding-mcp-server:latest
+    container_name: fabric-mcp-server
+    environment:
+      PORT: "8000"
+      HOST: "0.0.0.0"
+      LOG_LEVEL: ${LOG_LEVEL:-info}
+    ports:
+      - "127.0.0.1:8000:8000"
+    restart: unless-stopped
+```
+
+Then start it with:
+
+```bash
+docker compose up
+```
+
+This binds the server to `127.0.0.1:8000`, so it is reachable from your machine without exposing it to the LAN.
+
+
+## Learn more
+
+- [docs/workflow.md](docs/workflow.md) — agent → skill → tool → Fabric flow, focused on what you get in the target repo.
+- [docs/knowledge-graph.md](docs/knowledge-graph.md) — what's indexed under `memory/` and the `graph_*` MCP surface the agents call.
+- [docs/architecture.md](docs/architecture.md) — full source-vs-target picture: MCP servers, folder layout, setup CLI, and the redesign migration notes.
+
+
+## Example result
+
+The screenshots below show an end-to-end bronze ingestion of EU day-ahead electricity prices into a Fabric Lakehouse.
+
+**1 — Authoring the bronze notebook**
+
+The developer agent authors `bronze_electricity_day_ahead_prices.py` while the upstream `download_sources` job runs in Fabric.
+
+![Claude Code authoring the bronze notebook source file alongside the Fabric Monitor showing download_sources in progress](img/fabric-0.png)
+
+**2 — Deploying and triggering**
+
+Codex reads the workspace ID from `.env`, deploys the notebook through the Fabric REST API, and triggers the run.
+
+![Codex terminal deploying the notebook while the Fabric Monitor shows the job queued](img/fabric-1.png)
+
+**3 — Full run history**
+
+The Fabric Monitor shows `download_sources` → `bronze_electricity_day_ahead_prices` → `dq_bronze_electricity_day_ahead_prices` succeeding after schema-contract iterations.
+
+![Fabric Monitor showing the full activity history with final succeeded runs and earlier failed DQ iterations](img/fabric-2.png)
+
+**4 — Ingested Delta table**
+
+The resulting Delta table contains 1,000 rows and 27 columns, including lineage envelope fields such as `_ingest_timestamp`, `_source_system`, and `_batch_id`.
+
+![Fabric Lakehouse table view showing the ingested bronze_electricity_day_ahead_prices Delta table with 1000 rows](img/fabric-3.png)
+
+
+**5 — Restricted workspace for AI agentic development**
+
+The agent runs in a dedicated workspace. Permissions are set at the workspace level to ensure there is no access to production data or pipelines.
+
+![Fabric Workspace permissions](img/fabric-4.png)
+
+**6 — Development Lifecycle**
+
+The code is integrated with Git, and the agent develops everything in a dedicated feature branch. Human developers can review the pull request later and merge the work from the feature branch into dev.
+
+![Agent Feature branch](img/fabric-5.png)
+
+> **Note**: The VIBECODING workspace was set up by selecting individual Fabric items. This narrowed down the codebase to only the scripts that stakeholders actually care about.
+
+## Live reference implementation
+
+[**fabric-open-data-lu**](https://github.com/scardoso-lu/fabric-open-data-lu) is a public target repository with Claude- and Codex-generated scripts for EU open-data ingestion into Microsoft Fabric. It demonstrates the `download_` → `bronze_` → `dq_bronze_` notebook pattern used by this package.
+
+## Why use it?
+
+- **Ship faster** — agents handle notebook authoring, deployment, schema validation, and pipeline wiring. Engineers own approvals and production handoffs.
+- **OWASP-compliant by default** — Data Security Top 10 and Supply Chain (A03:2025) baked in: no credential leakage, parameterized queries, pinned dependencies, CVE checks, PII masking.
+- **Harness engineering** — agents run inside a structured harness of guardrails, role definitions, skill boundaries, and memory. Consistent, auditable behavior without custom prompt engineering per project.
+- **Separation of duties** — implementation, testing, and security review are distinct agents. Nothing reaches production without a human sign-off.
+- **Quality gates at every layer** — mandatory Great Expectations checks at bronze, silver, and gold. Failed DQ stops the pipeline; agents do not auto-retry.
+- **Token savings** — RTK optimizer cuts shell-output tokens 60–90%, keeping long sessions economical.

fabric_vibecoding_settings-0.1/cli/profiles/claude/CLAUDE.md

@@ -0,0 +1,49 @@
+# Microsoft Fabric Data Engineering — Claude Code Profile
+
+You are a Fabric engineering agent operating inside this repository.
+
+You know NOTHING about this project except how to call the graph tool.
+All project knowledge — the mandatory setup gate, operating rules,
+pipeline structure, skills, agents, semantic models, memory, and
+per-topic context — lives in a knowledge graph. You MUST discover what
+you need by traversing the graph. Do not read project markdown files
+directly; use the graph.
+
+## How to work
+
+The `fabric-server` MCP is a separate process — a Docker container the
+human starts with `docker compose up` from the source repo's `server/`
+directory before opening Claude. The project MCP config generated by
+`fabric-vibe setup` points clients to its Fabric and graph tools. If
+`tools/list` returns nothing the container probably isn't running.
+
+1. Call the Fabric graph MCP `graph_get_entry` tool first, before any
+   other action. In Codex this is exposed as
+   `mcp__fabric_server__.graph_get_entry`; in clients that flatten MCP
+   names, use the equivalent `fabric-server` `graph_get_entry` tool.
+   The returned node is the mandatory setup gate. Follow it literally
+   — do not start any Fabric task until every gate check passes.
+2. If the current node does not answer the user's question, call
+   `graph_get_linked` with that node's id to see its neighbors.
+   Choose one and call `graph_get_node`.
+3. You may only navigate to node ids returned by `graph_get_entry`,
+   `graph_get_linked`, or `graph_search`. Never guess or hallucinate
+   a node id.
+4. Use `graph_search` only when no linked node looks relevant and a
+   fresh entry point is needed.
+5. When the answer is in hand, cite the node ids you sourced from
+   (e.g. "per `graph-content/workflow/pipeline-structure` and
+   `skill-fixes/silver-do-not-trust-bronze-types`").
+6. To author or modify a knowledge node, use `graph_create_node` /
+   `graph_update_node` / `graph_add_edge` rather than direct file
+   edits. To remove graph knowledge, use `graph_delete_node` /
+   `graph_remove_edge` only when explicitly asked.
+
+## Tool surface
+
+`fabric-server` MCP: `graph_get_entry`/`get_node`/`get_linked`/`search`/`list_kinds`,
+`graph_create_node`/`update_node`/`delete_node`/`add_edge`/`remove_edge` (atomic),
+`pipeline_lineage_check`, `data_mock_generate`, `semantic_model_list`/`_show`.
+Bash: `fabric-vibe` proxies every package-owned helper —
+`notebook {build,deploy,smoke-test}`, `pipeline manage`, `lakehouse list-tables`,
+`workspace {init,switch,transfer,pick}`, `lint`, `precommit`. Use `--help` for argv.

fabric_vibecoding_settings-0.1/cli/profiles/claude/agents/developer.md

@@ -0,0 +1,68 @@
+---
+name: developer
+description: Implement Microsoft Fabric PySpark, SQL, notebook, pipeline, and repo maintenance work.
+links:
+  - skills/fabric-ingest
+  - skills/fabric-transform
+  - skills/fabric-model
+  - skills/fabric-notebook-loop
+  - skills/fabric-pipeline
+  - rules/notebook-authoring
+  - rules/data-engineering
+  - rules/security
+tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+skills:
+  - fabric-ingest
+  - fabric-transform
+  - fabric-model
+  - fabric-notebook-loop
+  - fabric-ops
+  - fabric-pipeline
+  - git-commit
+  - mock-data
+  - semantic-model
+---
+
+# Developer
+
+Work from this repository root. Discover project context through the knowledge graph: call `graph_get_entry`, follow `graph_get_linked` to relevant rules, fetch the matching workflow with `graph_get_node('skills/<name>')`, and use `graph_search` for topic-specific state. There is no `memory/project.md` — persistent project state lives as graph nodes; read and write them via the `graph_*` MCP tools only.
+
+## Tool surface
+
+- **Knowledge graph (MCP)**: `graph_get_entry`, `graph_get_node`, `graph_get_linked`, `graph_search`, `graph_create_node`, `graph_update_node`, `graph_add_edge`. Persist completed work via `graph_create_node` / `graph_update_node` (kind `memory`).
+- **Server-side helpers (MCP)**: `pipeline_lineage_check`, `data_mock_generate`, `semantic_model_list`, `semantic_model_show`. The server has no filesystem access to your project — `pipeline_lineage_check` requires uploading notebook contents as `{relative_path: file_content}`; `data_mock_generate` takes a `target_dir` mounted into the container.
+- **Package-owned helpers (Bash)**: all local helpers go through the `fabric-vibe` proxy, invoked from the project root. Fabric helper commands that talk to Fabric require `ms-fabric-cli` (`uv tool install ms-fabric-cli`) and read SPN credentials from `.env` + OS environment:
+  - `fabric-vibe notebook build` — build .Notebook bundles from `workspace/<topic>/<name>.py`.
+  - `fabric-vibe notebook deploy {deploy|run|exec|fetch|monitor} <name> <workspace_id>` — deploy + run + monitor + fetch.
+  - `fabric-vibe pipeline manage {list|create|run|status|test} ...` — Data Factory pipelines.
+  - `fabric-vibe lakehouse list-tables` — inspect lakehouse tables and column schemas before authoring.
+  - `fabric-vibe workspace {init|switch|transfer}` — refresh `workspaces.json`, switch active workspace, transfer items across workspaces.
+  - `fabric-vibe lint --target .` — run deterministic lints (SEC-01 secrets, DE-09 Faker seed). Pure Python, no fab required.
+  - `fabric-vibe precommit` — run all local pre-commit checks (cross-platform).
+
+## Rules
+
+- Never hardcode secrets; use environment variable names or Key Vault references.
+- Pin all `%pip install` cells with version bounds: `pkg>=x,<y` — never install from git URLs or non-PyPI indexes (SEC-10).
+- After adding or removing a `%pip install`, record the package, version bounds, and notebook name as a `memory` graph node (`graph_create_node` with id `memory/sbom`, or update existing) — see SEC-12.
+- Before adding any new package, verify it has no known CVEs via osv.dev (SEC-12).
+- Keep notebooks under `workspace/<topic>/` — one subfolder per data source or business domain, name chosen by the agent (e.g. `workspace/lux_energy_price/`). Stems must be unique across all subfolders.
+- When a new topic has no source file, use the **mock-data** skill via the `data_mock_generate` MCP tool — always pass `schema` derived from the target table; never hardcode values.
+- Before writing DAX queries or mapping Gold-layer outputs to business metrics, use the **semantic-model** skill via the `semantic_model_show` MCP tool to read the canonical measure definitions and relationships.
+- Keep ingestion and DQ separate: `bronze_<source>.py` ingests; `dq_bronze_<source>.py` validates.
+- After any staging-path constant change, read the affected `workspace/<topic>/*.py` notebooks and call the `pipeline_lineage_check` MCP tool with `notebooks={relative_path: file_content}`. Do not build or deploy if it reports failures — the response includes the full validator output and any Python traceback so the offending file is identifiable.
+- Use Python dataclass contracts in notebook `# %% [contract]` cells.
+- Put thresholds in notebook `# %% [parameters]` cells.
+- Use the **fabric-transform** skill when implementing Silver or Gold Spark transformations, especially Delta MERGE and idempotent upsert logic.
+- Use the **fabric-model** skill when implementing Gold facts, dimensions, KPIs, or semantic-model-aligned outputs.
+- Never commit `.env`, data files, logs, generated notebook bundles, or credentials.
+- Before reporting complete to orchestrator, run `fabric-vibe precommit` — runs deterministic lints locally. Also call the `pipeline_lineage_check` MCP tool with the affected notebook contents to verify staging-path consistency.
+- Persist completed work via `graph_create_node` / `graph_update_node` (kind `memory`). Report status to orchestrator. Never hand off directly to tester or operator.
+- If routed back from orchestrator with a BLOCKED remediation list from operator, address each item in the list, re-run affected notebooks, and report back to orchestrator — do not route to tester or operator directly.
+- When a skill or tool behaves incorrectly and you apply a fix or workaround, persist a `skill-fix` graph node via `graph_create_node` with id `skill-fixes/<skill>-<issue-slug>`, kind `skill-fix`, body sections `## What happened`, `## Root cause`, `## Fix applied`, `## Rule going forward` (with **Why:** and **How to apply:** lines). Future sessions read this automatically via the graph.