c4-architect-mcp 0.0.0-stage → 0.2.0-alpha.2
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.
- package/CHANGELOG.md +37 -0
- package/CODE_OF_CONDUCT.md +11 -0
- package/CONTRIBUTING.md +80 -0
- package/LICENSE +21 -0
- package/NOTICE +10 -0
- package/README.md +342 -2
- package/ROADMAP.md +59 -0
- package/SECURITY.md +27 -0
- package/THIRD_PARTY_NOTICES.md +21 -0
- package/dist/cli.js +99 -0
- package/dist/index.js +52 -0
- package/dist/model/config.js +94 -0
- package/dist/model/graph.js +340 -0
- package/dist/model/neighborhood.js +64 -0
- package/dist/parsers/astParser.js +241 -0
- package/dist/parsers/moduleResolver.js +181 -0
- package/dist/parsers/syntaxFacts.js +173 -0
- package/dist/renderers/artifacts.js +92 -0
- package/dist/renderers/c4Mermaid.js +123 -0
- package/dist/renderers/compactC4.js +173 -0
- package/dist/renderers/diagramExports.js +69 -0
- package/dist/version.js +2 -0
- package/docs/images/README.md +35 -0
- package/docs/images/component-20.png +0 -0
- package/docs/images/component-20.svg +3 -0
- package/docs/images/component-example.png +0 -0
- package/docs/images/component-example.svg +3 -0
- package/docs/images/export-toolbar.png +0 -0
- package/docs/images/hero.svg +7 -0
- package/docs/images/selection-example.png +0 -0
- package/docs/images/selection-example.svg +3 -0
- package/docs/images/workflow.svg +1 -0
- package/examples/README.md +54 -0
- package/examples/c4-architect.config.json +46 -0
- package/examples/order-service/src/api/orderController.ts +10 -0
- package/examples/order-service/src/inventory/index.ts +1 -0
- package/examples/order-service/src/inventory/reserveStock.ts +9 -0
- package/examples/order-service/src/orders/createOrder.ts +21 -0
- package/examples/order-service/src/orders/index.ts +3 -0
- package/examples/order-service/src/orders/types.ts +19 -0
- package/examples/order-service/src/payments/authorizePayment.ts +10 -0
- package/examples/order-service/src/storage/orderRepository.ts +10 -0
- package/examples/order-service/tsconfig.json +17 -0
- package/package.json +70 -4
- package/scripts/prepare-bin.mjs +4 -0
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
User-visible changes are recorded here. Unreleased work is not a published package or release.
|
|
4
|
+
|
|
5
|
+
## 0.2.0-alpha.2 — 2026-11-06
|
|
6
|
+
|
|
7
|
+
### Added
|
|
8
|
+
|
|
9
|
+
- Render a focused neighborhood from a saved graph through `render_architecture_graph` or CLI `render --node`. Choose a direction and set depth, node, and relationship limits. Focused artifacts show the view's scope and include relationship source locations.
|
|
10
|
+
|
|
11
|
+
### Fixed
|
|
12
|
+
|
|
13
|
+
- Recognize TypeScript `export type *` re-exports as type-only dependencies.
|
|
14
|
+
- Parse UTF-8, UTF-16LE, and UTF-16BE sources that start with a byte order mark and preserve the hash of the original bytes.
|
|
15
|
+
- Report existing local assets reached through relative imports, TypeScript `paths` aliases, or `baseUrl` as unsupported local modules.
|
|
16
|
+
- Compare snapshots across checkout directories and reconcile equivalent import spellings by resolved endpoints, kind, label, and protocol while preserving relationship multiplicity.
|
|
17
|
+
|
|
18
|
+
## 0.2.0-alpha.1 — 2026-11-06
|
|
19
|
+
|
|
20
|
+
### Added
|
|
21
|
+
|
|
22
|
+
- A versioned graph foundation with source evidence, file hashes, explicit boundary mapping, diagnostics, summaries, bounded neighborhood queries, and graph comparisons.
|
|
23
|
+
- Local TypeScript/TSX dependency analysis and module-resolution regression fixtures.
|
|
24
|
+
- Compact server-side C4 image layout with orthogonal routing and compatible Mermaid source export.
|
|
25
|
+
- PNG, SVG, Markdown, and self-contained interactive HTML artifacts.
|
|
26
|
+
- Component and relationship selection, directional highlighting, keyboard controls, and full-diagram PNG/SVG exports preserving the current selection.
|
|
27
|
+
- Synthetic 12-node and 20-node layout, interaction, and export regression cases.
|
|
28
|
+
- Public-alpha documentation, contribution guidance, issue templates, a security policy, a code of conduct, and cross-platform CI configuration.
|
|
29
|
+
- Direct CLI analysis, rendering, summaries, queries, and comparisons alongside the local MCP server.
|
|
30
|
+
- Version-pinned npm/npx installation and client configuration instructions.
|
|
31
|
+
- MIT licensing and dependency notices.
|
|
32
|
+
|
|
33
|
+
### Clarified
|
|
34
|
+
|
|
35
|
+
- Observed source dependencies, inferred classifications, and declared architecture boundaries are distinct.
|
|
36
|
+
- Static imports do not prove runtime behavior, deployment boundaries, network protocols, or security properties.
|
|
37
|
+
- Draw.io, Structurizr DSL, publishing, cross-repository mapping, additional languages, and assisted threat modeling remain roadmap items.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Code of Conduct
|
|
2
|
+
|
|
3
|
+
Help keep this project useful and welcoming. Treat people with respect, explain your reasoning, and critique the work rather than the person. Different experience levels, backgrounds, and accessibility needs are welcome.
|
|
4
|
+
|
|
5
|
+
Harassment, threats, discriminatory abuse, sexualized conduct, doxxing, and repeated personal attacks are not acceptable. Do not post another person's private information or contact them repeatedly after being asked to stop.
|
|
6
|
+
|
|
7
|
+
Maintainers may edit or remove content, close a discussion, warn a participant, or restrict participation when needed to protect the community. They should explain decisions where practical and handle reports with care. This policy applies in project issues, pull requests, reviews, and other project-managed spaces.
|
|
8
|
+
|
|
9
|
+
To report a concern, contact a maintainer through a private contact method listed on their GitHub profile. If none is available, open an issue requesting a private conduct-reporting channel without naming affected people or describing sensitive details publicly. Reports involving a maintainer should go to another maintainer when one is available.
|
|
10
|
+
|
|
11
|
+
Good-faith disagreement, a rejected proposal, and a request for evidence are normal parts of collaboration. Keep the discussion focused, specific, and open to correction.
|
package/CONTRIBUTING.md
ADDED
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# Contributing
|
|
2
|
+
|
|
3
|
+
Thanks for helping make code-derived architecture easier to inspect. This project is an alpha: focused fixes, reproducible examples, and clear limits are more useful than broad capability claims.
|
|
4
|
+
|
|
5
|
+
## Start with a small case
|
|
6
|
+
|
|
7
|
+
For a bug, include the smallest source fixture or graph that reproduces it, the expected result, the actual result, and relevant diagnostics. For a diagram problem, attach the full SVG or HTML when possible, along with a screenshot of the affected area.
|
|
8
|
+
|
|
9
|
+
For a new parser, output format, or publishing integration, open a feature request before building a large change. Explain the user workflow, its relationship to the shared graph contract, and how it will be tested. The [roadmap](ROADMAP.md) gives the current direction.
|
|
10
|
+
|
|
11
|
+
Do not include proprietary code, credentials, personal data, or internal hostnames in issues, fixtures, screenshots, or generated diagrams. Replace them with a small synthetic example that preserves the problem.
|
|
12
|
+
|
|
13
|
+
## Local setup
|
|
14
|
+
|
|
15
|
+
Use Node.js 22 or 24 and npm:
|
|
16
|
+
|
|
17
|
+
```sh
|
|
18
|
+
git clone https://github.com/zrack/c4-architect-mcp.git
|
|
19
|
+
cd c4-architect-mcp
|
|
20
|
+
npm ci
|
|
21
|
+
npm test
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
`npm test` builds the server and runs the test suite. Use `npm run dev` to watch TypeScript changes. MCP clients launch the built `dist/index.js`; rebuild and reconnect the server before testing a change through a client.
|
|
25
|
+
|
|
26
|
+
Run the browser checks when changing layout, SVG, HTML interaction, or exports:
|
|
27
|
+
|
|
28
|
+
```sh
|
|
29
|
+
npx playwright install chromium
|
|
30
|
+
C4_BROWSER_CHANNEL=chromium npm run test:layout
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
On Linux, Playwright may need `npx playwright install --with-deps chromium`. In PowerShell, set `$env:C4_BROWSER_CHANNEL = "chromium"` before running the test. Installed Google Chrome is the default when this variable is absent.
|
|
34
|
+
|
|
35
|
+
Generated fixtures and browser reports are under `output/playwright/component-scale/`. Review the actual images and selected exports as well as the test result.
|
|
36
|
+
|
|
37
|
+
## Project map
|
|
38
|
+
|
|
39
|
+
| Location | Responsibility |
|
|
40
|
+
| --- | --- |
|
|
41
|
+
| `src/index.ts` | MCP tool contracts and local artifact writes. |
|
|
42
|
+
| `src/parsers/` | Source extraction and module resolution. |
|
|
43
|
+
| `src/model/` | Versioned graph, boundary configuration, projections, and graph operations. |
|
|
44
|
+
| `src/renderers/` | Mermaid export, compact layout, images, and interactive HTML. |
|
|
45
|
+
| `test/` | Contract and regression tests with small fixtures. |
|
|
46
|
+
| `scripts/` | Build, packaging, and browser verification helpers. |
|
|
47
|
+
| `docs/images/` | Repository documentation artwork and generated examples. |
|
|
48
|
+
|
|
49
|
+
## Keep the graph honest
|
|
50
|
+
|
|
51
|
+
- An observed import is a code dependency. Do not turn it into a runtime protocol or deployment claim without supporting evidence.
|
|
52
|
+
- Preserve source evidence and diagnostics when adding extraction or resolution behavior.
|
|
53
|
+
- Keep declared boundaries separate from generated results. Stable IDs matter for rescans and comparisons.
|
|
54
|
+
- Report unsupported or unresolved cases explicitly. Silently dropping an edge can make a diagram misleading.
|
|
55
|
+
- Validate external input at the tool boundary, including duplicate identifiers and missing relationship endpoints.
|
|
56
|
+
- Keep bounded query limits and truncation visible to callers.
|
|
57
|
+
|
|
58
|
+
A parser fix should include a fixture that fails before the change and verifies the relevant edge, evidence, or diagnostic afterward. Avoid tests that simply repeat the implementation. A renderer fix should exercise the real output, including labels and interaction when affected.
|
|
59
|
+
|
|
60
|
+
## Pull requests
|
|
61
|
+
|
|
62
|
+
Keep a pull request focused enough to explain in a few paragraphs. Describe the concrete problem, resulting behavior, and relevant validation. Include a before/after image for visual changes and note any graph-schema or tool-contract changes.
|
|
63
|
+
|
|
64
|
+
Before requesting review:
|
|
65
|
+
|
|
66
|
+
1. Run `npm test`.
|
|
67
|
+
2. Run `npm run test:package` for runtime dependencies, packaging, or CLI changes.
|
|
68
|
+
3. Run `npm run test:layout` for renderer or interaction changes.
|
|
69
|
+
4. Update examples and documentation affected by the change.
|
|
70
|
+
5. Check that generated artifacts contain no private source or machine-specific paths.
|
|
71
|
+
|
|
72
|
+
The CI workflow also checks Node.js 22 and 24 on Linux, macOS, and Windows. A local pass does not replace those platform results.
|
|
73
|
+
|
|
74
|
+
AI-assisted contributions are welcome. You are responsible for understanding the change, checking its evidence, and verifying its behavior. Mention limitations that a reviewer should know.
|
|
75
|
+
|
|
76
|
+
## License and conduct
|
|
77
|
+
|
|
78
|
+
By contributing, you agree that your contribution may be distributed under the project's [MIT License](LICENSE). Submit only material you have the right to contribute. There is no separate contributor license agreement.
|
|
79
|
+
|
|
80
|
+
Follow the [Code of Conduct](CODE_OF_CONDUCT.md). For a possible vulnerability, follow [SECURITY.md](SECURITY.md) instead of posting sensitive details in a public issue.
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Scott Zeitner and contributors
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/NOTICE
ADDED
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
C4-Architect MCP Server
|
|
2
|
+
Copyright (c) 2026 Scott Zeitner and contributors
|
|
3
|
+
|
|
4
|
+
Project source and project-authored documentation are licensed under MIT.
|
|
5
|
+
Dependencies retain their own licenses. See THIRD_PARTY_NOTICES.md and the
|
|
6
|
+
license/notice files distributed with the installed dependency packages.
|
|
7
|
+
|
|
8
|
+
C4 is a modeling approach created by Simon Brown. This is an independent
|
|
9
|
+
project and is not affiliated with or endorsed by the C4 model, the Model
|
|
10
|
+
Context Protocol project, OpenAI, Anthropic, or Eclipse.
|
package/README.md
CHANGED
|
@@ -1,3 +1,343 @@
|
|
|
1
|
-
|
|
1
|
+

|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
# C4 Architect
|
|
4
|
+
|
|
5
|
+
**Explore a TypeScript codebase without pasting the whole repository into a prompt.**
|
|
6
|
+
|
|
7
|
+
C4 Architect is a local [Model Context Protocol](https://modelcontextprotocol.io/) server that turns source imports into a versioned dependency graph, lets you review and name its architectural boundaries, and produces compact C4 diagrams. Use it from Codex, Claude Code, Claude Desktop, or another client that supports local MCP servers over `stdio`.
|
|
8
|
+
|
|
9
|
+
**0.2.0-alpha.2 · TypeScript / TSX · Local parsing · MIT licensed**
|
|
10
|
+
|
|
11
|
+
[Get started](#get-started) · [npm package](https://www.npmjs.com/package/c4-architect-mcp) · [See the diagrams](#read-the-diagram) · [Contribute](https://github.com/zrack/c4-architect-mcp/blob/main/CONTRIBUTING.md) · [Roadmap](https://github.com/zrack/c4-architect-mcp/blob/main/ROADMAP.md)
|
|
12
|
+
|
|
13
|
+

|
|
14
|
+
|
|
15
|
+
## Start with evidence
|
|
16
|
+
|
|
17
|
+
An import is evidence of a code dependency. It does not, by itself, prove that two modules are separately deployed services, that an SDK call uses a particular protocol, or that a data flow is secure.
|
|
18
|
+
|
|
19
|
+
C4 Architect keeps that distinction visible. Source locations and content hashes support observed dependencies. Naming heuristics remain inferences. A separate boundary configuration records the systems, containers, and components that a person has declared. Rescanning the source preserves those declarations.
|
|
20
|
+
|
|
21
|
+
The result is a starting point for application and solution architecture review. Runtime behavior, organization structure, and enterprise architecture still need other evidence.
|
|
22
|
+
|
|
23
|
+
| Available in this alpha | Purpose |
|
|
24
|
+
| --- | --- |
|
|
25
|
+
| Local Tree-sitter analysis | Extract TypeScript and TSX dependencies without an LLM parsing the source files. |
|
|
26
|
+
| Versioned graph and source evidence | Save a graph for review, with source locations, file hashes, and analysis diagnostics. |
|
|
27
|
+
| Explicit boundary mapping | Give systems, containers, and components stable names through a separate configuration file. |
|
|
28
|
+
| Summary, neighborhood queries, and comparison | Inspect a saved graph without returning the entire graph every time. |
|
|
29
|
+
| Context, Container, and Component diagrams | Render a graph projection or a graph supplied by the caller. |
|
|
30
|
+
| Compact PNG, SVG, and interactive HTML | Trace orthogonal connections, inspect relationship labels, and export a selected view. |
|
|
31
|
+
|
|
32
|
+
Draw.io, Structurizr DSL, wiki publishing, cross-repository mapping, additional languages, and assisted threat modeling are **planned**, not implemented. See the [roadmap](https://github.com/zrack/c4-architect-mcp/blob/main/ROADMAP.md).
|
|
33
|
+
|
|
34
|
+
## Get started
|
|
35
|
+
|
|
36
|
+
Use Node.js 22 or 24 and npm. Run the pinned alpha without a checkout:
|
|
37
|
+
|
|
38
|
+
```sh
|
|
39
|
+
npx -y c4-architect-mcp@0.2.0-alpha.2 --help
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
The examples pin `0.2.0-alpha.2` for a repeatable setup. `c4-architect-mcp@alpha` follows the prerelease channel and currently selects `0.2.0-alpha.2`. npm's `latest` tag remains on `0.2.0-alpha.1`, the initial prerelease. There is no stable release yet.
|
|
43
|
+
|
|
44
|
+
The server communicates over `stdio`; starting it without a subcommand waits for an MCP client rather than opening a browser page or an HTTP port. The following configurations let your client start it through `npx`.
|
|
45
|
+
|
|
46
|
+
<details>
|
|
47
|
+
<summary><strong>Codex</strong></summary>
|
|
48
|
+
|
|
49
|
+
Add this to `~/.codex/config.toml`, or use the MCP server settings in the Codex desktop app:
|
|
50
|
+
|
|
51
|
+
```toml
|
|
52
|
+
[mcp_servers.c4-architect]
|
|
53
|
+
command = "npx"
|
|
54
|
+
args = ["-y", "c4-architect-mcp@0.2.0-alpha.2"]
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
You can also register it from the Codex CLI:
|
|
58
|
+
|
|
59
|
+
```sh
|
|
60
|
+
codex mcp add c4-architect -- npx -y c4-architect-mcp@0.2.0-alpha.2
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Reconnect the server after configuration changes. See the [official Codex MCP setup guide](https://learn.chatgpt.com/docs/extend/mcp).
|
|
64
|
+
|
|
65
|
+
</details>
|
|
66
|
+
|
|
67
|
+
<details>
|
|
68
|
+
<summary><strong>Claude Code</strong></summary>
|
|
69
|
+
|
|
70
|
+
```sh
|
|
71
|
+
claude mcp add --transport stdio c4-architect -- npx -y c4-architect-mcp@0.2.0-alpha.2
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Use `/mcp` to inspect the connection. See the [official Claude Code MCP documentation](https://code.claude.com/docs/en/mcp).
|
|
75
|
+
|
|
76
|
+
</details>
|
|
77
|
+
|
|
78
|
+
<details>
|
|
79
|
+
<summary><strong>Claude Desktop</strong></summary>
|
|
80
|
+
|
|
81
|
+
Open **Settings → Developer → Edit Config** and merge this entry with your existing `mcpServers` configuration:
|
|
82
|
+
|
|
83
|
+
```json
|
|
84
|
+
{
|
|
85
|
+
"mcpServers": {
|
|
86
|
+
"c4-architect": {
|
|
87
|
+
"command": "npx",
|
|
88
|
+
"args": ["-y", "c4-architect-mcp@0.2.0-alpha.2"]
|
|
89
|
+
}
|
|
90
|
+
}
|
|
91
|
+
}
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
Completely restart Claude Desktop after saving. For Windows JSON paths, use forward slashes or escape each backslash. See the [official local MCP server setup guide](https://modelcontextprotocol.io/docs/develop/connect-local-servers).
|
|
95
|
+
|
|
96
|
+
</details>
|
|
97
|
+
|
|
98
|
+
These are local `stdio` configurations. Verify the connection in your chosen client. If a desktop app cannot find `npx`, use the executable's absolute path. On Windows, a client that cannot launch `npx` directly can use `command: "cmd"` with `args: ["/c", "npx", "-y", "c4-architect-mcp@0.2.0-alpha.2"]`.
|
|
99
|
+
|
|
100
|
+
### Optional global installation
|
|
101
|
+
|
|
102
|
+
```sh
|
|
103
|
+
npm install -g c4-architect-mcp@0.2.0-alpha.2
|
|
104
|
+
c4-architect-mcp --help
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
With a global installation, use `c4-architect-mcp` as the MCP command with no arguments, or use it in place of the pinned `npx` command below. Use an absolute executable path if your desktop client's PATH differs from your terminal's.
|
|
108
|
+
|
|
109
|
+
### Use the CLI directly
|
|
110
|
+
|
|
111
|
+
You can analyze and render without an MCP client:
|
|
112
|
+
|
|
113
|
+
```sh
|
|
114
|
+
npx -y c4-architect-mcp@0.2.0-alpha.2 analyze /absolute/path/to/project/src --level Component --out /absolute/path/to/project/architecture.graph.json --summary
|
|
115
|
+
npx -y c4-architect-mcp@0.2.0-alpha.2 summary /absolute/path/to/project/architecture.graph.json
|
|
116
|
+
npx -y c4-architect-mcp@0.2.0-alpha.2 render /absolute/path/to/project/architecture.graph.json --out /absolute/path/to/project/ARCHITECTURE.md
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Replace `/absolute/path/to/project` with your project's location. Open the generated `ARCHITECTURE.html` beside the Markdown to explore the diagram.
|
|
120
|
+
|
|
121
|
+
For explicit compiler settings, add `--tsconfig /absolute/path/to/tsconfig.json` to `analyze`. The nearest `tsconfig.json` is otherwise discovered and read as data. Boundary configuration is loaded only when `--config` is supplied. The CLI also provides `query` and `diff` commands; `--help` lists their options.
|
|
122
|
+
|
|
123
|
+
### Run from a checkout or try the sample
|
|
124
|
+
|
|
125
|
+
Clone the repository to contribute, inspect the source, or try the included [synthetic order-service example](https://github.com/zrack/c4-architect-mcp/blob/main/examples/README.md):
|
|
126
|
+
|
|
127
|
+
```sh
|
|
128
|
+
git clone https://github.com/zrack/c4-architect-mcp.git
|
|
129
|
+
cd c4-architect-mcp
|
|
130
|
+
npm ci
|
|
131
|
+
npm test
|
|
132
|
+
node dist/index.js analyze examples/order-service/src --level Component --config examples/c4-architect.config.json --out output/order-service.graph.json --summary
|
|
133
|
+
node dist/index.js render output/order-service.graph.json --out output/ORDER-SERVICE.md
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
`npm test` builds `dist/index.js` and runs the automated tests. Open `output/ORDER-SERVICE.html` to explore the sample. To connect an MCP client to your checkout, use `node` as the command and the absolute path to `dist/index.js` as its only argument. After changing TypeScript, run `npm run build` and reconnect the server to load the new code.
|
|
137
|
+
|
|
138
|
+
## Analyze a project
|
|
139
|
+
|
|
140
|
+
Ask your connected client:
|
|
141
|
+
|
|
142
|
+
> Use c4-architect to analyze `/absolute/path/to/project/src` at the Component level. Save the graph to `/absolute/path/to/project/architecture.graph.json` and return a summary. Review the diagnostics and inferred boundaries, then use `render_architecture_graph` to save `/absolute/path/to/project/ARCHITECTURE.md`.
|
|
143
|
+
|
|
144
|
+
The analysis tool accepts:
|
|
145
|
+
|
|
146
|
+
```json
|
|
147
|
+
{
|
|
148
|
+
"targetDir": "/absolute/path/to/project/src",
|
|
149
|
+
"c4Level": "Component",
|
|
150
|
+
"outputPath": "/absolute/path/to/project/architecture.graph.json",
|
|
151
|
+
"responseMode": "summary"
|
|
152
|
+
}
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
`responseMode: "summary"` saves the complete graph locally and returns counts and status, keeping it out of the model's context until needed. It requires `outputPath`. The default `"graph"` mode returns the graph.
|
|
156
|
+
|
|
157
|
+
Use absolute paths: an MCP client's working directory may differ from the repository you want to analyze. Check diagnostics before treating a missing edge as an absent dependency. Static analysis cannot resolve every computed import or establish every runtime connection.
|
|
158
|
+
|
|
159
|
+
The current parser covers `.ts` and `.tsx`, excluding declaration files, dependency/build/output directories, and symlink trees. It uses one nearest or explicitly supplied `tsconfig.json` per scan; nested project configurations are not orchestrated automatically. Static imports, re-exports, and literal `import()` / `require()` dependencies are supported; computed dependencies and parse problems remain visible through diagnostics.
|
|
160
|
+
|
|
161
|
+
Existing CSS, SVG, and other local assets found through relative imports, `paths` aliases, or `baseUrl` produce an `UNSUPPORTED_MODULE_TYPE` diagnostic. The graph contains the TypeScript/TSX dependencies. An unresolved specifier that matches a configured alias produces an `UNRESOLVED_IMPORT` diagnostic.
|
|
162
|
+
|
|
163
|
+
To name architectural boundaries, supply `configPath` explicitly. The [example configuration](https://github.com/zrack/c4-architect-mcp/blob/main/examples/c4-architect.config.json) demonstrates the format:
|
|
164
|
+
|
|
165
|
+
```json
|
|
166
|
+
{
|
|
167
|
+
"schemaVersion": "1.0",
|
|
168
|
+
"system": { "id": "shop", "label": "Shop" },
|
|
169
|
+
"defaultContainer": {
|
|
170
|
+
"id": "application",
|
|
171
|
+
"label": "Application",
|
|
172
|
+
"technology": "TypeScript / Node.js"
|
|
173
|
+
},
|
|
174
|
+
"components": [
|
|
175
|
+
{ "id": "orders", "label": "Order orchestration", "paths": ["orders"] },
|
|
176
|
+
{ "id": "payments", "label": "Payments", "paths": ["payments"] }
|
|
177
|
+
]
|
|
178
|
+
}
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
`paths` are literal file or directory prefixes relative to `targetDir`, not globs. Give a component a `containerId` when mapping it into an explicitly configured container. Ambiguous matches are rejected. Unmapped files use the default container, which is inferred unless you configure it. Keep this configuration separate from the generated graph.
|
|
182
|
+
|
|
183
|
+
```json
|
|
184
|
+
{
|
|
185
|
+
"targetDir": "/absolute/path/to/project/src",
|
|
186
|
+
"c4Level": "Component",
|
|
187
|
+
"configPath": "/absolute/path/to/project/c4-architect.config.json",
|
|
188
|
+
"tsconfigPath": "/absolute/path/to/project/tsconfig.json",
|
|
189
|
+
"outputPath": "/absolute/path/to/project/architecture.graph.json",
|
|
190
|
+
"responseMode": "summary"
|
|
191
|
+
}
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
## Inspect before drawing
|
|
195
|
+
|
|
196
|
+
| Tool | Input | Result |
|
|
197
|
+
| --- | --- | --- |
|
|
198
|
+
| `analyze_architectural_boundaries` | `targetDir`, `c4Level`; optional `configPath`, `tsconfigPath`, `outputPath`, `responseMode` | A saved graph, full response, or compact summary at the requested C4 level. |
|
|
199
|
+
| `get_architecture_summary` | `graphPath` | A compact overview of a saved graph and its diagnostics. |
|
|
200
|
+
| `query_architecture_graph` | `graphPath`; optional `nodeId`, `search`, `direction`, `maxDepth`, `maxNodes`, `maxEdges`, `maxBytes`, `includeEvidence` | A bounded neighborhood or search, with truncation reported. |
|
|
201
|
+
| `compare_architecture_graphs` | `beforePath`, `afterPath`; optional `limit`, `maxBytes` | Change counts and bounded details for snapshots at the same C4 level. |
|
|
202
|
+
| `render_architecture_graph` | `graphPath`; optional `title`, `outputPath`, `focus` | Render a saved graph or a focused neighborhood. |
|
|
203
|
+
| `render_c4_mermaid` | `title`, `c4Level`, `nodes`, `relationships`, optional `outputPath` | Mermaid source and a compact server-rendered PNG; saved SVG, PNG, HTML, and Markdown when requested. |
|
|
204
|
+
|
|
205
|
+
Queries default to `direction: "both"`, `maxDepth: 1`, `maxNodes: 25`, `maxEdges: 50`, and `maxBytes: 16000`. Source evidence is opt-in. Start with a summary, then search for a component or request its incoming or outgoing dependencies. Smaller views are usually easier to review than a complete repository drawing.
|
|
206
|
+
|
|
207
|
+
Render a saved graph directly:
|
|
208
|
+
|
|
209
|
+
```json
|
|
210
|
+
{
|
|
211
|
+
"graphPath": "/absolute/path/to/project/architecture.graph.json",
|
|
212
|
+
"outputPath": "/absolute/path/to/project/ARCHITECTURE.md"
|
|
213
|
+
}
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
For caller-supplied graphs, `render_c4_mermaid` remains available. To adapt an analysis projection manually, preserve its `nodes` and convert its `edges`:
|
|
217
|
+
|
|
218
|
+
```js
|
|
219
|
+
const relationships = analysis.edges.map(edge => ({
|
|
220
|
+
from: edge.source,
|
|
221
|
+
to: edge.target,
|
|
222
|
+
label: edge.label,
|
|
223
|
+
technology: edge.protocol === "unknown" ? undefined : edge.protocol,
|
|
224
|
+
}));
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
Analysis levels are `Context`, `Container`, and `Component`; renderer levels are `C4Context`, `C4Container`, and `C4Component`. Do not invent a protocol when the analysis has no evidence for it.
|
|
228
|
+
|
|
229
|
+
### Focus a diagram on one node
|
|
230
|
+
|
|
231
|
+
Use `query --search` to find the exact node ID for a focused diagram. These commands use the graph from the checkout example and show the outgoing dependencies of Order orchestration.
|
|
232
|
+
|
|
233
|
+
```sh
|
|
234
|
+
npx -y c4-architect-mcp@0.2.0-alpha.2 query output/order-service.graph.json --search "Order orchestration" --depth 0
|
|
235
|
+
npx -y c4-architect-mcp@0.2.0-alpha.2 render output/order-service.graph.json --node component:orders --direction outgoing --out output/ORDER-SERVICE.outgoing.md
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
With `--node`, render defaults to both directions, depth 1, 25 nodes, and 50 relationships. Use `--direction incoming` or `--direction outgoing` to trace one direction. Set `--depth`, `--nodes`, and `--edges` to adjust the view. The diagram caption shows how much of the saved graph is included. The render result reports omitted nodes and relationships and whether a node or relationship limit was reached.
|
|
239
|
+
|
|
240
|
+
The focused Markdown relationship table and interactive HTML details show up to three source locations per relationship. Use the saved graph for the full evidence.
|
|
241
|
+
|
|
242
|
+
For MCP, pass `focus` to `render_architecture_graph`. Find the ID with `query_architecture_graph` using `search`.
|
|
243
|
+
|
|
244
|
+
```json
|
|
245
|
+
{
|
|
246
|
+
"graphPath": "/absolute/path/to/project/architecture.graph.json",
|
|
247
|
+
"outputPath": "/absolute/path/to/project/ARCHITECTURE.orders.md",
|
|
248
|
+
"focus": {
|
|
249
|
+
"nodeId": "component:orders",
|
|
250
|
+
"direction": "outgoing",
|
|
251
|
+
"maxDepth": 1,
|
|
252
|
+
"maxNodes": 25,
|
|
253
|
+
"maxEdges": 50
|
|
254
|
+
}
|
|
255
|
+
}
|
|
256
|
+
```
|
|
257
|
+
|
|
258
|
+
## Read the diagram
|
|
259
|
+
|
|
260
|
+

|
|
261
|
+
|
|
262
|
+
*Five declared components and five source-observed dependencies from the checked-in [order-service example](https://github.com/zrack/c4-architect-mcp/blob/main/examples/README.md). The application is synthetic; the dependencies come from its actual source imports.*
|
|
263
|
+
|
|
264
|
+
[Full-size PNG](https://raw.githubusercontent.com/zrack/c4-architect-mcp/main/docs/images/component-example.png) · [Scalable SVG](https://raw.githubusercontent.com/zrack/c4-architect-mcp/main/docs/images/component-example.svg)
|
|
265
|
+
|
|
266
|
+
The server computes the image layout with ELK, compares horizontal and vertical arrangements, and reserves space for the wrapped labels it draws. PNG and SVG rendering do not require a browser at runtime. Mermaid remains a compatible source export; a client's Mermaid layout may differ from the server image.
|
|
267
|
+
|
|
268
|
+
The saved graph preserves the system/container hierarchy. The current image renderer draws a flat view, with parent-container and inferred-boundary information in node descriptions rather than nested boundary boxes. Inspect those descriptions in the interactive view.
|
|
269
|
+
|
|
270
|
+
Saving `ARCHITECTURE.md` also writes `ARCHITECTURE.svg`, `ARCHITECTURE.png`, and `ARCHITECTURE.html` beside it. The Markdown shows the PNG, links to the interactive view, includes a relationship table, and retains the Mermaid source in a collapsed section.
|
|
271
|
+
|
|
272
|
+
<details>
|
|
273
|
+
<summary><strong>Explore the larger 20-node renderer example</strong></summary>
|
|
274
|
+
|
|
275
|
+

|
|
276
|
+
|
|
277
|
+
This separate stress fixture has 20 nodes and 35 relationships, including branching, cycles, shared dependencies, and long labels. Its connections are authored test data rather than extracted source dependencies.
|
|
278
|
+
|
|
279
|
+
[Full-size PNG](https://raw.githubusercontent.com/zrack/c4-architect-mcp/main/docs/images/component-20.png) · [Scalable SVG](https://raw.githubusercontent.com/zrack/c4-architect-mcp/main/docs/images/component-20.svg)
|
|
280
|
+
|
|
281
|
+
</details>
|
|
282
|
+
|
|
283
|
+

|
|
284
|
+
|
|
285
|
+
*The 20-node stress fixture with Order orchestration selected, saved through the interactive view's export buttons.*
|
|
286
|
+
|
|
287
|
+
[Full-size selected PNG](https://raw.githubusercontent.com/zrack/c4-architect-mcp/main/docs/images/selection-example.png) · [Scalable selected SVG](https://raw.githubusercontent.com/zrack/c4-architect-mcp/main/docs/images/selection-example.svg)
|
|
288
|
+
|
|
289
|
+
Select a component to highlight outgoing connections in blue and incoming connections in brown. Other routes fade. Select a relationship ID to isolate that route and inspect its full label. Zoom, keyboard selection, Escape, and **Show all** help you move between details and the complete picture.
|
|
290
|
+
|
|
291
|
+

|
|
292
|
+
|
|
293
|
+
**Export PNG** and **Export SVG** preserve the current selection and connection highlighting across the full diagram, regardless of zoom or scroll position. PNG exports at twice the diagram's natural dimensions; SVG remains scalable. The self-contained HTML works as a local file without contacting the MCP server or an external service.
|
|
294
|
+
|
|
295
|
+
Automatic layout cannot make every graph readable at every size. Crossings can remain, and a large full-graph image may need zoom. Use selection and bounded graph queries to follow a particular change or dependency.
|
|
296
|
+
|
|
297
|
+
See [image provenance and regeneration instructions](https://github.com/zrack/c4-architect-mcp/blob/main/docs/images/README.md) to reproduce these examples.
|
|
298
|
+
|
|
299
|
+
## Local execution and data
|
|
300
|
+
|
|
301
|
+
The parser reads local source files and does not call an LLM API. Generated diagrams and their interaction code are self-contained. Your MCP client receives the tool results, and its own settings determine whether those results are sent to a model or another service. Review those settings before analyzing private source.
|
|
302
|
+
|
|
303
|
+
Analysis is static; it does not run the analyzed application's code. Output options write the requested graph and diagram files. See [SECURITY.md](https://github.com/zrack/c4-architect-mcp/blob/main/SECURITY.md) for the security scope and reporting process.
|
|
304
|
+
|
|
305
|
+
## Develop and verify
|
|
306
|
+
|
|
307
|
+
From a repository checkout:
|
|
308
|
+
|
|
309
|
+
```sh
|
|
310
|
+
npm ci
|
|
311
|
+
npm test
|
|
312
|
+
npm run test:package
|
|
313
|
+
npm run test:layout
|
|
314
|
+
```
|
|
315
|
+
|
|
316
|
+
The regular tests cover parsing, graph contracts, graph operations, rendering, and MCP behavior. The package check exercises a packed installation. The layout check uses real browser geometry and downloads against synthetic 12-node and 20-node fixtures. It checks labels, routes, arrowheads, compactness, highlighting, keyboard controls, and selection-aware PNG/SVG exports.
|
|
317
|
+
|
|
318
|
+
The layout check uses installed Google Chrome by default. To use Playwright Chromium:
|
|
319
|
+
|
|
320
|
+
```sh
|
|
321
|
+
npx playwright install chromium
|
|
322
|
+
C4_BROWSER_CHANNEL=chromium npm run test:layout
|
|
323
|
+
```
|
|
324
|
+
|
|
325
|
+
For PowerShell, set `$env:C4_BROWSER_CHANNEL = "chromium"` before running the test. Browser reports and generated fixtures are written under `output/playwright/component-scale/`. These checks cover the included cases, not every possible graph topology.
|
|
326
|
+
|
|
327
|
+
The [CI workflow](https://github.com/zrack/c4-architect-mcp/blob/main/.github/workflows/ci.yml) configures tests on Node.js 22 and 24 across Linux, macOS, and Windows, plus a Chromium layout job. See the [GitHub Actions runs](https://github.com/zrack/c4-architect-mcp/actions) for results.
|
|
328
|
+
|
|
329
|
+
## Build this with us
|
|
330
|
+
|
|
331
|
+
Useful contributions start with a concrete case: an import that resolves incorrectly, a boundary that is hard to express, or a diagram whose route is difficult to follow. Small, sanitized fixtures are especially valuable.
|
|
332
|
+
|
|
333
|
+
- **Report a bug:** include a minimal input, expected result, diagnostics, and a screenshot for rendering problems.
|
|
334
|
+
- **Improve analysis:** add source evidence and a regression fixture; keep observed facts separate from inference.
|
|
335
|
+
- **Improve diagrams:** test the actual SVG and exported images, including selected views.
|
|
336
|
+
- **Design an extension:** discuss its graph contract before adding a new language, renderer, or publisher.
|
|
337
|
+
- **Improve documentation:** try the setup on your platform and client, and report the exact versions used.
|
|
338
|
+
|
|
339
|
+
Read [CONTRIBUTING.md](https://github.com/zrack/c4-architect-mcp/blob/main/CONTRIBUTING.md), the [Code of Conduct](https://github.com/zrack/c4-architect-mcp/blob/main/CODE_OF_CONDUCT.md), and the [roadmap](https://github.com/zrack/c4-architect-mcp/blob/main/ROADMAP.md). Public API details may change during the alpha; preserve a copy of important graph snapshots and boundary configurations.
|
|
340
|
+
|
|
341
|
+
## License
|
|
342
|
+
|
|
343
|
+
C4 Architect is available under the [MIT License](https://github.com/zrack/c4-architect-mcp/blob/main/LICENSE). You may use, modify, and redistribute it, including commercially, subject to the license terms. Dependency licenses and attribution requirements remain applicable; see [NOTICE](https://github.com/zrack/c4-architect-mcp/blob/main/NOTICE) and [third-party notices](https://github.com/zrack/c4-architect-mcp/blob/main/THIRD_PARTY_NOTICES.md).
|
package/ROADMAP.md
ADDED
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Roadmap
|
|
2
|
+
|
|
3
|
+
The goal is a dependable path from local code evidence to architecture views that people can inspect, correct, and maintain. A readable diagram matters, but so does knowing why a line exists and what it does not establish.
|
|
4
|
+
|
|
5
|
+
This is a direction, not a release schedule. Features marked planned are not available in the current server.
|
|
6
|
+
|
|
7
|
+
## 1. Trustworthy local foundation — current alpha
|
|
8
|
+
|
|
9
|
+
The first release centers on TypeScript and TSX over local `stdio` MCP connections.
|
|
10
|
+
|
|
11
|
+
- Extract dependencies locally with Tree-sitter and resolve supported modules using project configuration.
|
|
12
|
+
- Preserve source locations, file hashes, parse diagnostics, and unresolved dependencies.
|
|
13
|
+
- Separate observed source facts, inferred classifications, and declared architecture boundaries.
|
|
14
|
+
- Keep manual mapping in a separate versioned configuration, with stable declared identifiers.
|
|
15
|
+
- Save a versioned graph; summarize it, query a bounded neighborhood, and compare snapshots.
|
|
16
|
+
- Render C4 Context, Container, and Component views, with compact PNG/SVG output and interactive connection highlighting.
|
|
17
|
+
- Export full-size PNG/SVG images with the current selection.
|
|
18
|
+
- Maintain parser, graph, MCP, package, and browser layout regression checks.
|
|
19
|
+
- Prepare documentation, licensing, contribution guidance, and CI for a public alpha.
|
|
20
|
+
|
|
21
|
+
The checked-in code and tests are the source of truth for supported cases. Public availability and package publication are separate release steps.
|
|
22
|
+
|
|
23
|
+
## 2. Make repeated use practical — next
|
|
24
|
+
|
|
25
|
+
Make the graph useful throughout a project's life, rather than treating each drawing as a fresh prompt.
|
|
26
|
+
|
|
27
|
+
- Expand module-resolution fixtures from real, sanitized project examples.
|
|
28
|
+
- Add incremental analysis and caching with explicit invalidation rules.
|
|
29
|
+
- Improve graph slicing, search, and explanations for large repositories.
|
|
30
|
+
- Make graph comparison useful in pull requests without treating every source edit as an architecture change.
|
|
31
|
+
- Extend client and platform compatibility testing with reproducible reports.
|
|
32
|
+
- Add a documented extension contract before accepting additional language parsers.
|
|
33
|
+
|
|
34
|
+
Acceptance matters more than feature count: unresolved analysis must stay visible, repeated scans must retain declared identities, and bounded responses must report truncation.
|
|
35
|
+
|
|
36
|
+
## 3. Editable formats and documentation delivery — planned
|
|
37
|
+
|
|
38
|
+
Add outputs that reuse the same graph, hierarchy, identifiers, and evidence.
|
|
39
|
+
|
|
40
|
+
- **Draw.io XML (`render_c4_drawio`):** editable diagrams with meaningful groups and preserved relationship labels.
|
|
41
|
+
- **Structurizr DSL (`render_structurizr_dsl`):** validated workspace output with explicit C4 hierarchy.
|
|
42
|
+
- **Publishing:** choose one initial target, such as an Azure DevOps wiki, before expanding to Confluence or Notion.
|
|
43
|
+
|
|
44
|
+
Publishing needs a previewable change, predictable ownership of generated content, and credentials supplied outside the graph. Git-backed wiki delivery and API publishing are alternatives to evaluate, not promises of two simultaneous implementations.
|
|
45
|
+
|
|
46
|
+
## 4. Distributed systems and assisted review — planned
|
|
47
|
+
|
|
48
|
+
Code imports are only one source of architectural evidence. Larger views need explicit connections to contracts and infrastructure.
|
|
49
|
+
|
|
50
|
+
- Combine repositories through a declared manifest with repository identities and revisions.
|
|
51
|
+
- Add evidence from API contracts, deployment files, and service configuration before inferring inter-service links.
|
|
52
|
+
- Support additional languages through tested parser extensions.
|
|
53
|
+
- Explore assisted STRIDE review using declared trust boundaries and evidence-backed flows.
|
|
54
|
+
|
|
55
|
+
Threat-model output would identify review questions and hypotheses. An import graph alone cannot prove exposed ports, unencrypted traffic, or exploitable vulnerabilities.
|
|
56
|
+
|
|
57
|
+
## Propose a feature
|
|
58
|
+
|
|
59
|
+
Open a feature request with a concrete workflow, a small example, the expected graph or view, and a way to test success. Prefer an extension of the shared graph contract over a renderer-specific interpretation of source code. See [CONTRIBUTING.md](CONTRIBUTING.md).
|
package/SECURITY.md
ADDED
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Security
|
|
2
|
+
|
|
3
|
+
## Scope
|
|
4
|
+
|
|
5
|
+
C4 Architect is a local `stdio` MCP server. It reads source files from the requested directory, analyzes them statically, and can write graph and diagram artifacts to requested paths. It does not execute the analyzed application's code. It is not a sandbox for untrusted clients or a vulnerability scanner.
|
|
6
|
+
|
|
7
|
+
Treat access to the server as access to the local files its process can read and write. Use the MCP client's permissions and the operating system's process permissions to limit that access. Tool results can include source paths, dependency names, and architecture details; the client's data-handling settings apply after those results are returned.
|
|
8
|
+
|
|
9
|
+
The parser runs locally without an LLM API call. Saved interactive HTML, SVG, and PNG assets are self-contained. These properties do not imply that an MCP host will keep tool responses on the machine.
|
|
10
|
+
|
|
11
|
+
## Supported versions
|
|
12
|
+
|
|
13
|
+
Security fixes target the latest alpha code. Older alpha snapshots are not maintained separately. Rebuild and reconnect a local server after updating it.
|
|
14
|
+
|
|
15
|
+
## Report a vulnerability
|
|
16
|
+
|
|
17
|
+
Use [GitHub's private vulnerability reporting](https://github.com/zrack/c4-architect-mcp/security/advisories/new) when it is enabled for this repository. If private reporting is unavailable, open an issue asking the maintainer for a private reporting channel **without including the vulnerability details, a working exploit, credentials, or private source**.
|
|
18
|
+
|
|
19
|
+
Include the affected revision, platform and Node.js version, a minimal reproduction, expected impact, and any relevant generated artifact. A sanitized local example is preferable to production data.
|
|
20
|
+
|
|
21
|
+
Do not test against another person's repository, client, or infrastructure without their authorization. The project has no paid bug-bounty program or guaranteed response time.
|
|
22
|
+
|
|
23
|
+
## Areas that matter
|
|
24
|
+
|
|
25
|
+
Security-sensitive changes include source traversal and module resolution, output-path handling, package installation behavior, graph input validation, escaping untrusted labels in Mermaid/XML/HTML, and standalone HTML export behavior. Changes that introduce network access, application-code execution, credentials, or publishing require an explicit design and documentation update.
|
|
26
|
+
|
|
27
|
+
Architecture classification and future threat-model features are analysis aids. They must not present inferred runtime connections or possible security concerns as verified vulnerabilities.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Third-party notices
|
|
2
|
+
|
|
3
|
+
C4-Architect's own source is MIT licensed. That does not relicense its dependencies. npm installs those packages separately with their upstream license and notice files. Keep those notices when redistributing dependencies or bundling the application.
|
|
4
|
+
|
|
5
|
+
The direct runtime dependencies in this alpha are:
|
|
6
|
+
|
|
7
|
+
| Dependency | Version | Upstream license |
|
|
8
|
+
|---|---|---|
|
|
9
|
+
| `@modelcontextprotocol/sdk` | 1.32.2 | MIT |
|
|
10
|
+
| `tree-sitter` | 0.21.1 | MIT |
|
|
11
|
+
| `tree-sitter-typescript` | 0.21.2 | MIT |
|
|
12
|
+
| `zod` | 4.6.7 | MIT |
|
|
13
|
+
| `typescript` | 5.9.3 | Apache-2.0 |
|
|
14
|
+
| `elkjs` | 0.12.1 | EPL-2.0 OR GPL-3.0-or-later |
|
|
15
|
+
| `sharp` | 0.35.5 | Apache-2.0 |
|
|
16
|
+
|
|
17
|
+
Use the EPL-2.0 option for ELK.js in this distribution. Its upstream license is included in `node_modules/elkjs/LICENSE.md`. This project does not modify or vendor ELK.js source.
|
|
18
|
+
|
|
19
|
+
Sharp's optional native dependencies depend on platform and installation choices. The tested macOS ARM64 installation includes `@img/sharp-libvips-darwin-arm64` 1.3.4 under LGPL-3.0-or-later. Read the package's bundled notices and Sharp's [installation and licensing documentation](https://sharp.pixelplumbing.com/install/), including the notices for libvips and its libraries, before redistributing native binaries.
|
|
20
|
+
|
|
21
|
+
The lockfile records transitive packages. Their licenses are provided in each installed package; this table is a direct-dependency guide, not an exhaustive replacement for upstream notices. Development tools (including Mermaid and Playwright) are not bundled in the runtime package. Generated diagrams are not assigned a separate license by this tool; their content may reflect the source or model supplied by the user.
|