release: SpecBridge v1.0.0

.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
       "name": "specbridge",
       "source": "./integrations/claude-code-plugin/specbridge",
       "description": "Kiro-compatible spec workflows, verified interactive task execution, and deterministic drift checks.",
-      "version": "0.7.1",
+      "version": "1.0.0",
       "license": "MIT",
       "keywords": [
         "spec-driven-development",

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,84 @@
+name: Bug report
+description: Report a reproducible problem in SpecBridge
+title: "[bug] "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the report. Reproducible bugs in documented behavior — especially anything
+        touching the security model or `.kiro` file integrity — get priority.
+
+        **Security issues do not belong here.** Report them privately per
+        [SECURITY.md](https://github.com/HelloThisWorld/specbridge/blob/main/SECURITY.md).
+  - type: input
+    id: version
+    attributes:
+      label: SpecBridge version
+      description: Output of `specbridge --version`, plus how you installed it (npm, plugin, source).
+      placeholder: "1.0.0 (npm)"
+    validations:
+      required: true
+  - type: input
+    id: platform
+    attributes:
+      label: Platform
+      description: Operating system and version.
+      placeholder: "Windows 11 Pro 26100 / macOS 15.3 / Ubuntu 24.04"
+    validations:
+      required: true
+  - type: input
+    id: node-version
+    attributes:
+      label: Node.js version
+      description: Output of `node --version` (Node >= 20 is required).
+      placeholder: "v20.17.0"
+    validations:
+      required: true
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened
+      description: The exact command you ran and what SpecBridge did, including error output.
+      placeholder: |
+        Command:
+        Output:
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: What you expected
+      description: What documented behavior you expected instead.
+    validations:
+      required: true
+  - type: textarea
+    id: doctor-output
+    attributes:
+      label: "`specbridge doctor` output"
+      description: >
+        Paste the output of `specbridge doctor --json` with sensitive paths redacted.
+        It prints no secret values by design, but paths can reveal machine or project names.
+      render: json
+    validations:
+      required: false
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Reproduction steps
+      description: >
+        The smallest sequence that reproduces the issue — ideally against a tiny synthetic
+        `.kiro` workspace. Numbered steps beat prose.
+      placeholder: |
+        1. Create a workspace with ...
+        2. Run `specbridge ...`
+        3. Observe ...
+    validations:
+      required: true
+  - type: checkboxes
+    id: hygiene
+    attributes:
+      label: Report hygiene
+      options:
+        - label: I removed all credentials, API keys, and proprietary company content from this report.
+          required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Documentation
+    url: https://github.com/HelloThisWorld/specbridge/tree/main/docs
+    about: Guides for every area — start here for usage questions before opening an issue.
+  - name: Security reports (private)
+    url: https://github.com/HelloThisWorld/specbridge/blob/main/SECURITY.md
+    about: Never report vulnerabilities in a public issue — see the reporting instructions.

.github/ISSUE_TEMPLATE/extension_contribution.yml

@@ -0,0 +1,83 @@
+name: Extension contribution
+description: Propose an extension for the community registry index
+title: "[extension] "
+labels: ["extension", "registry"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        The registry lists **metadata only** — your code stays in your repository and your
+        archive stays on your HTTPS host. Read
+        [registry/CONTRIBUTING.md](https://github.com/HelloThisWorld/specbridge/blob/main/registry/CONTRIBUTING.md)
+        first: the actual contribution is a pull request adding
+        `registry/entries/<your-extension-id>.json`; this issue is for proposing and
+        discussing it.
+
+        Before filing, your extension should pass:
+        ```
+        specbridge extension validate ./my-extension
+        specbridge extension conformance ./my-extension --yes
+        specbridge extension package ./my-extension
+        ```
+  - type: input
+    id: extension-id
+    attributes:
+      label: Extension ID
+      description: "Must match the extension ID grammar: lowercase letters and digits in hyphen-separated segments, starting with a letter, max 64 characters."
+      placeholder: "security-analyzer"
+    validations:
+      required: true
+  - type: dropdown
+    id: kind
+    attributes:
+      label: Kind
+      options:
+        - template-provider
+        - analyzer
+        - verifier
+        - exporter
+        - runner
+    validations:
+      required: true
+  - type: input
+    id: repo-url
+    attributes:
+      label: Source repository URL
+      description: Public HTTPS URL of the extension's source repository.
+      placeholder: "https://github.com/you/security-analyzer"
+    validations:
+      required: true
+  - type: textarea
+    id: checksum
+    attributes:
+      label: Archive hosting and checksum
+      description: >
+        The stable, credential-free HTTPS URL of your packaged
+        `.specbridge-extension.zip` and the exact archive SHA-256 printed by
+        `specbridge extension package`. The registry entry must carry both for every version.
+      placeholder: |
+        archiveUrl: https://github.com/you/security-analyzer/releases/download/v1.0.0/security-analyzer-1.0.0.specbridge-extension.zip
+        sha256: <64 hex characters>
+    validations:
+      required: true
+  - type: textarea
+    id: permissions
+    attributes:
+      label: Permissions requested
+      description: >
+        The exact `permissions` block from your manifest (specRead, repositoryRead,
+        repositoryWrite, network, childProcess, environmentVariables). It must match the
+        manifest inside the archive byte-for-byte — understating permissions is grounds
+        for removal.
+      render: json
+    validations:
+      required: true
+  - type: checkboxes
+    id: terms
+    attributes:
+      label: Registry terms
+      options:
+        - label: I understand that registry listing is not endorsement, review, or a security guarantee, and that checksums prove integrity, not publisher identity.
+          required: true
+        - label: My entry declares every permission the manifest declares, my archive is hosted at a stable credential-free HTTPS URL, and I will publish new versions as new entries rather than changing published archives in place.
+          required: true

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,44 @@
+name: Feature request
+description: Propose an improvement or new capability for SpecBridge
+title: "[feature] "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Feature discussions work best when grounded in a concrete problem. Note that some
+        requests are bounded by the project's invariants — SpecBridge will not add features
+        that execute untrusted content, bypass permission systems, treat model claims as
+        evidence, or mutate `.kiro`/Git state automatically.
+  - type: textarea
+    id: problem
+    attributes:
+      label: The problem
+      description: What are you trying to do that SpecBridge currently makes hard or impossible? Describe the workflow, not just the missing flag.
+    validations:
+      required: true
+  - type: textarea
+    id: proposed-solution
+    attributes:
+      label: Proposed solution
+      description: How you imagine it working — CLI commands, configuration, MCP tools, output. Sketches welcome.
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: Other approaches you tried or considered (including workarounds, templates, or extensions) and why they fall short.
+    validations:
+      required: false
+  - type: dropdown
+    id: contribution
+    attributes:
+      label: Willingness to contribute
+      description: Would you implement this yourself if the design is agreed?
+      options:
+        - I would open a PR for this
+        - I could help test or review
+        - I am only proposing the idea
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/template_contribution.yml

@@ -0,0 +1,56 @@
+name: Template contribution
+description: Propose a built-in spec template pack
+title: "[template] "
+labels: ["template"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Built-in templates are data, not code: a JSON manifest plus Markdown files with
+        one-pass `{{variable}}` substitution — no scripts, no network, no model. Read
+        [docs/template-contribution-guide.md](https://github.com/HelloThisWorld/specbridge/blob/main/docs/template-contribution-guide.md)
+        for the pack layout, the generated artifacts, and the automatic test gate.
+  - type: input
+    id: template-id
+    attributes:
+      label: Template ID
+      description: The manifest `id`, which must equal the pack directory name under `packages/templates/builtins/`.
+      placeholder: "graphql-api"
+    validations:
+      required: true
+  - type: dropdown
+    id: kind
+    attributes:
+      label: Kind
+      description: Which spec kind the template generates.
+      options:
+        - feature
+        - bugfix
+    validations:
+      required: true
+  - type: textarea
+    id: modes
+    attributes:
+      label: Modes and variables
+      description: Which stages the pack provides (requirements/bugfix, design, tasks) and the variables it declares, with their constraints.
+      placeholder: |
+        Stages: requirements, design, tasks
+        Variables: serviceName (required), storageBackend (optional, default "postgres")
+    validations:
+      required: true
+  - type: textarea
+    id: scaffolds
+    attributes:
+      label: What it scaffolds
+      description: What the rendered spec covers and why it is broadly reusable rather than project-specific. Which existing built-in is it closest to, and why is it not a variant of that one?
+    validations:
+      required: true
+  - type: checkboxes
+    id: guarantees
+    attributes:
+      label: Template guarantees
+      options:
+        - label: Rendering is fully offline and deterministic — the pack is plain UTF-8 Markdown plus a JSON manifest, uses only `{{variable}}` substitution, and contains no scripts, no symlinks, no network references, and no environment-dependent content.
+          required: true
+        - label: I removed all credentials and proprietary company content; examples are synthetic.
+          required: true

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,26 @@
+# Summary
+
+<!-- What this PR changes and why. One or two paragraphs; link the design
+     discussion if there was one. -->
+
+Closes #<!-- issue number, or remove this line -->
+
+## Checklist
+
+- [ ] `pnpm lint`, `pnpm typecheck`, and `pnpm test` pass locally
+- [ ] `pnpm check:public-contracts` passes — or a stable contract changed
+      **intentionally** and the snapshot under `contracts/` is updated in
+      this PR
+- [ ] Documentation updated for any user-visible behavior change
+- [ ] CHANGELOG entry added for any user-visible change (required whenever
+      a contract snapshot changed)
+- [ ] Everything is in English (code, comments, docs, commit messages)
+- [ ] No employer or client proprietary content — examples and fixtures
+      are synthetic
+- [ ] No credentials, tokens, or secret values anywhere in the diff,
+      fixtures, or recorded test output
+
+<!-- Security-relevant change? Read SECURITY.md and
+     docs/security/threat-model.md first, and say here which invariants
+     the change touches. Never describe an unfixed vulnerability in a
+     public PR. -->

.github/workflows/ci.yml

@@ -45,6 +45,12 @@ jobs:
       - name: Test (compatibility fixtures, round-trip byte identity, CLI, drift, action)
         run: pnpm test
 
+      - name: Large-repository performance suite (informational budgets)
+        # Heavy ~9,000-file fixtures: one representative combination is enough,
+        # and isolating it keeps the main test run's workers responsive.
+        if: matrix.os == 'ubuntu-latest' && matrix.node == 20
+        run: pnpm test:perf
+
       - name: CLI smoke test against the example Kiro workspace
         run: node scripts/smoke.mjs
 
@@ -54,6 +60,25 @@ jobs:
       - name: Template gallery matches the built-in manifests
         run: pnpm check:template-gallery
 
+      - name: Public contract snapshots match the built surface
+        run: pnpm check:public-contracts
+
+      - name: Deterministic security scan (credentials, bypass strings, bundle paths)
+        run: pnpm check:security
+
+      - name: Extension registry validates and matches the reference extensions
+        run: |
+          pnpm validate:extension-registry
+          pnpm check:extension-registry
+          pnpm check:builtin-registry
+          pnpm check:extension-gallery
+
+      - name: Generated MCP tool reference matches the registry
+        run: pnpm check:mcp-docs
+
+      - name: Example projects run offline with expected output
+        run: node scripts/validate-examples.mjs
+
       - name: GitHub Action bundle is reproducible
         if: matrix.os == 'ubuntu-latest'
         run: git diff --exit-code integrations/github-action/dist