feat(community): establish contributor foundation

Add 0BSD licensing, contributor guidance, fast pull request CI, and public task specifications.

Include the license in the generated devcontainer release bundle.

Author: codegeist-ai

.github/workflows/ci.yml

@@ -0,0 +1,28 @@
+# ci.yml - run the fast contributor contract without publishing or heavy images
+
+name: CI
+
+on:
+  pull_request:
+    branches:
+      - main
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  check:
+    name: Check
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out source
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+      - name: Install Task
+        uses: go-task/setup-task@01a4adf9db2d14c1de7a560f09170b6e0df736aa # v2.1.0
+        with:
+          version: 3.52.0
+      - name: Run contributor checks
+        run: task check

.oc_local/rules/software-tests.md

@@ -2,11 +2,19 @@
 
 Use this rule when making code, script, or workflow changes in this repository.
 
-## Full Suite Default
+## Normal Check
 
-- Run the complete `task tests-run` suite before handing off changes.
-- Targeted tests are still useful while iterating, but they do not replace the
-  final full-suite attempt.
+- Run `task check` as the normal deterministic verification before handing off
+  changes. It covers shell syntax and focused source-to-release contracts
+  without Docker, QEMU, browser, or Dev Containers builds.
+- Keep the focused release fixture in a cleanup-trapped OS temporary directory
+  and copy only its explicit source inputs. `task check` must not create
+  `.test-tmp/` or copy ignored workspace state, caches, profiles, or logs.
+- Run the complete `task tests-run` suite when changes affect the image, Dev
+  Containers lifecycle, Docker/Compose behavior, QEMU, browser runtime, or
+  another integration contract covered only by that suite.
+- Targeted tests are still useful while iterating, but they do not replace a
+  relevant final `task check` or broad-suite attempt.
 - Do not run `docker system prune`, `docker builder prune`, or other Docker
   cleanup commands automatically before tests. If Docker storage is too tight,
   stop and ask for approval before pruning cache, images, containers, or volumes.

CONTRIBUTING.md

@@ -0,0 +1,86 @@
+# Contributing To The Devcontainer Kit
+
+Contributions improve the shared development environment used by Codegeist
+repositories. Start with a GitHub Issue when proposing behavior, toolchain, or
+workflow changes, and keep pull requests focused on one reviewable outcome.
+
+## Repository Ownership
+
+This repository owns the generic VS Code Dev Containers runtime, its image
+toolchain, host-side initialization, shared runtime scripts, release assembly,
+tests, and kit-specific documentation.
+
+The `main` branch is the canonical source and contribution target. The
+`release` branch is generated from reviewed source by `scripts/release-build.sh`
+and contains only the runtime files consumed at `.devcontainer/`. Do not use a
+generated `release` checkout, or a consuming repository's `.devcontainer/`
+submodule checkout, as an implementation target.
+
+## Contribution Workflow
+
+1. Check the repository's [Issues](https://github.com/codegeist-ai/codegeist-devcontainer-kit/issues)
+   and [roadmap listing](https://github.com/users/codegeist-ai/projects/1) before
+   starting overlapping work.
+2. Link the Issue to a local task under `docs/tasks/` when the work needs a
+   resumable specification. Follow the [task guide](docs/tasks/README.md).
+3. Make the smallest source change on a branch based on `main`.
+4. Run the normal deterministic check:
+
+   ```bash
+   task check
+   ```
+
+5. Run `task tests-run` when changing the image, Dev Containers lifecycle,
+   Docker/Compose behavior, QEMU, browser runtime, or another contract covered
+   only by the broad integration suite.
+6. Open a pull request that links the public Issue and local task, explains the
+   source and release impact, and records the verification performed.
+
+`task check` validates shell syntax and focused source-to-release contracts. It
+is non-interactive, does not build the image or start Docker, QEMU, Dev
+Containers, or browsers, and does not publish or modify this repository's Git
+history. Its focused release fixture copies only required source inputs into a
+cleanup-trapped OS temporary directory, so the check leaves no repo-local test
+directory, cache, log, or copied local state behind.
+
+## Extension Boundaries
+
+Keep shared, repository-agnostic runtime behavior in this source repository.
+Consuming repositories should use `.codegeist/.local.env`,
+`.codegeist/compose.local.yml`, and `.codegeist/Dockerfile` for documented
+runtime extensions instead of editing `.devcontainer/`. Project-specific
+OpenCode behavior belongs in the consuming repository's `.oc_local/` overlay,
+not in its `.opencode/` or `.devcontainer/` submodule.
+
+Do not edit this source repository's nested `.devcontainer/` or `.opencode/`
+submodules as part of ordinary kit work.
+
+## Release Publication
+
+Release publication is maintainer-only. Contributors should not run the
+release-publishing workflow or push the generated `release` branch. Maintainers
+publish only from clean, reviewed `main` after the full release verification
+gate documented in `README.md` has passed.
+
+## Shared Policies
+
+Codegeist's account-wide policies apply here and are maintained centrally:
+
+The visible [Codegeist personal account profile](https://github.com/codegeist-ai)
+is sourced from
+[`codegeist-ai/codegeist-ai`](https://github.com/codegeist-ai/codegeist-ai).
+The separate [`codegeist-ai/.github`](https://github.com/codegeist-ai/.github)
+repository remains the source for shared community defaults used here and in
+other Codegeist repositories.
+
+- [Code of Conduct](https://github.com/codegeist-ai/.github/blob/main/CODE_OF_CONDUCT.md)
+- [Security Policy](https://github.com/codegeist-ai/.github/blob/main/SECURITY.md)
+- [Support Policy](https://github.com/codegeist-ai/.github/blob/main/SUPPORT.md)
+
+Do not report vulnerabilities in a public Issue; follow the shared Security
+Policy.
+
+## License
+
+Contributions are provided under the repository's
+[Zero-Clause BSD (`0BSD`) license](LICENSE).

LICENSE

@@ -0,0 +1,7 @@
+BSD Zero Clause License
+
+Copyright (C) 2026 Codegeist contributors
+
+Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

README.md

@@ -7,6 +7,9 @@ Containers workflow with the current Codegeist/planner development toolchain.
 
 This repository is a reusable devcontainer kit that can be added to other
 repositories at `.devcontainer/`, either as a Git subtree or as a Git submodule.
+The `main` branch is the canonical source and contribution target. The generated
+`release` branch is the runtime-only tree intended for consuming
+`.devcontainer/` submodules and is not an implementation target.
 The source `Dockerfile.base` intentionally carries the full
 Codegeist/planner-style toolchain, including Docker CE, Node 24, VS Code,
 GitHub CLI, Maven, GraalVM, JBang, Hugo, Nix, PowerShell through `pwsh`, Task
@@ -17,6 +20,17 @@ security scan tools, password-store tooling through `pass`, and related CLI
 tools. The release build publishes this file as
 `.devcontainer/Dockerfile` for consuming repositories.
 
+Project work is tracked through
+[GitHub Issues](https://github.com/codegeist-ai/codegeist-devcontainer-kit/issues),
+the [Codegeist roadmap listing](https://github.com/users/codegeist-ai/projects/1),
+and resumable local specifications described in the
+[task guide](docs/tasks/README.md). See [CONTRIBUTING.md](CONTRIBUTING.md) for the
+source workflow and extension boundaries. Codegeist's shared
+[Code of Conduct](https://github.com/codegeist-ai/.github/blob/main/CODE_OF_CONDUCT.md),
+[Security Policy](https://github.com/codegeist-ai/.github/blob/main/SECURITY.md),
+and [Support Policy](https://github.com/codegeist-ai/.github/blob/main/SUPPORT.md)
+apply to this repository.
+
 The consuming project should use the standard VS Code flow:
 
 1. Clone the consuming repository.
@@ -373,7 +387,22 @@ If the repository was already cloned without submodules, initialize them later:
 git submodule update --init --recursive
 ```
 
-Run the local test suite from this repository root:
+Run the normal fast, deterministic contributor check from this repository root:
+
+```bash
+task check
+```
+
+This validates shell syntax and the focused source-to-release contract without
+building the image, starting Docker, QEMU, Dev Containers, or browsers,
+publishing a release, or modifying this repository's Git history. The release
+fixture uses a bounded source input list under a cleanup-trapped OS temporary
+directory and leaves no `.test-tmp`, cache, log, or copied local state in the
+source checkout.
+
+Run the broad local test suite when changing image contents, Dev Containers
+lifecycle behavior, Docker/Compose integration, QEMU, browser runtime, or another
+contract covered only by integration tests:
 
 ```bash
 task tests-run
@@ -431,6 +460,7 @@ The release branch tree contains only:
 .oc_local.opencode.json.example
 Dockerfile
 Dockerfile.example
+LICENSE
 README.md
 compose.local.yml.example
 devcontainer.json
@@ -443,7 +473,8 @@ scripts/chrome.sh
 `scripts/release-build.sh` copies source `Dockerfile.base` into the release tree
 as `Dockerfile` and ships `Dockerfile.example` as the on-demand template for root
 `.codegeist/Dockerfile`; do not add a tracked root `Dockerfile` to the source
-checkout for the kit base image.
+checkout for the kit base image. The source and generated runtime trees both ship
+the canonical 0BSD `LICENSE`.
 
 ## OpenCode Workspace
 
@@ -1021,3 +1052,13 @@ Prefer:
 - The base image currently keeps the copied Codegeist/planner toolchain intact;
   future work can split generic tools from project-specific features when there
   is a concrete consumer need.
+
+The public roadmap listing is maintained at
+<https://github.com/users/codegeist-ai/projects/1>. Contributor-sized work should
+start from a GitHub Issue and, when implementation detail needs durable handoff,
+a linked specification under `docs/tasks/`.
+
+## License
+
+This repository and its generated runtime release are available under the
+[Zero-Clause BSD (`0BSD`) license](LICENSE).

README_release.md

@@ -17,6 +17,37 @@ tests, and local AI workflow support. The image toolchain includes PowerShell as
 `pwsh` for cross-platform shell and automation work, Task with Bash completion,
 shared terminal-capture tools for documentation previews, plus shared QEMU and
 security-scan tools for infrastructure checks inside consuming devcontainers.
+The runtime tree includes the repository's [`LICENSE`](LICENSE) and is
+distributed under the Zero-Clause BSD (`0BSD`) license.
+
+## Project And Contributions
+
+Changes to the kit belong on the source repository's `main` branch, not in this
+generated `release` tree or a consuming repository's `.devcontainer/` checkout.
+Use the source repository's
+[contributor guide](https://github.com/codegeist-ai/codegeist-devcontainer-kit/blob/main/CONTRIBUTING.md),
+[GitHub Issues](https://github.com/codegeist-ai/codegeist-devcontainer-kit/issues),
+[task guide](https://github.com/codegeist-ai/codegeist-devcontainer-kit/blob/main/docs/tasks/README.md),
+and [Codegeist roadmap listing](https://github.com/users/codegeist-ai/projects/1)
+to propose and track work.
+
+In a source `main` checkout, run `task check` as the normal fast contributor
+check. Run the broader `task tests-run` suite when a change affects the image,
+Dev Containers lifecycle, Docker/Compose behavior, QEMU, or browser runtime.
+The fast check uses cleanup-trapped OS temporary state and leaves no repo-local
+test directory behind. These source tasks are intentionally omitted from the
+generated runtime tree.
+
+Codegeist's account-wide
+[Code of Conduct](https://github.com/codegeist-ai/.github/blob/main/CODE_OF_CONDUCT.md),
+[Security Policy](https://github.com/codegeist-ai/.github/blob/main/SECURITY.md),
+and [Support Policy](https://github.com/codegeist-ai/.github/blob/main/SUPPORT.md)
+apply without being duplicated in this runtime tree.
+
+## Release Notes
+
+- The generated runtime manifest includes the canonical root `LICENSE`, so the
+  license travels with every `.devcontainer/` release checkout.
 
 ## Consumer Setup
 

Taskfile.yaml

@@ -19,6 +19,7 @@
 # - tests/code-open-test.sh
 # - scripts/chrome.sh
 # - tests/browser-open-test.sh
+# - tests/release-build.sh
 
 version: '3'
 
@@ -38,6 +39,17 @@ vars:
     sh: printf '%s' "${CONTAINER_GID:-${UID:-$(id -u)}}"
 
 tasks:
+  check:
+    desc: Run fast deterministic contributor checks
+    cmds:
+      - >-
+        bash -n
+        "{{.TASKFILE_DIR}}/entrypoint.sh"
+        "{{.TASKFILE_DIR}}/initialize.sh"
+        "{{.TASKFILE_DIR}}"/scripts/*.sh
+        "{{.TASKFILE_DIR}}"/tests/*.sh
+      - '"{{.TASKFILE_DIR}}/tests/release-build.sh"'
+
   docker-build:
     desc: Build the generic devcontainer kit image
     cmds:

docs/memory-bank/chat.md

@@ -23,13 +23,18 @@
   simultaneous first-time `BRANCH` starts.
 - OpenCode work should continue from this repository root in the current
   maintenance checkout.
+- The repository-local contributor baseline now targets source `main`: 0BSD
+  licensing, a local contribution guide, Issue-to-task-to-PR linkage, and
+  read-only CI all use `task check` as the normal fast contract.
+- Contributor rollout remains open until the pending public Issues, pull request,
+  and roadmap/GitHub state are created outside this repository.
 
 ## Current State
 
 - Local default branch is `main`.
-- `.devcontainer/` and `.opencode/` are checked-out shared submodules in this
-  development repository. Do not edit them directly during normal project work
-  unless the task is explicit submodule work.
+- `.devcontainer/` and `.opencode/` are configured shared submodules in this
+  development repository. When initialized, do not edit them directly during
+  normal project work unless the task is explicit submodule work.
 - `.devcontainer` is a runtime-release submodule. Release workflows may update
   its gitlink to the latest pushed `origin/release` commit, but should not
   automatically commit that parent gitlink after publishing unless the user asks.
@@ -201,9 +206,12 @@
   must not open VS Code or start/remove containers.
 - Tests should exercise the real Dev Containers lifecycle when behavior depends
   on VS Code or the Dev Containers CLI integration.
-- Test fixtures now use repo-local ignored temp roots (`.test-tmp/` and
-  `.browser-smoke-tmp/`) because Docker bind mounts in this workspace cannot rely
-  on arbitrary `/tmp` paths being visible to the daemon.
+- Docker-backed broad-suite fixtures use repo-local ignored temp roots
+  (`.test-tmp/` and `.browser-smoke-tmp/`) because bind mounts cannot rely on
+  arbitrary `/tmp` paths being visible to the daemon. The normal `task check`
+  release fixture does not need Docker: it copies only explicit release source
+  inputs into cleanup-trapped OS temporary state and leaves no repo-local test
+  directory behind.
 - Browser UI verification uses `tests/browser-ui-cdp.mjs`, a Node 24 Chrome
   DevTools Protocol driver invoked by `tests/browser-smoke.sh`. It covers both
   headless rendering and the real local VS Code failure shape: a Dev Containers
@@ -222,9 +230,11 @@
   insecure. Manual Google sign-in succeeded after launching
   `chrome https://accounts.google.com` from the terminal with the updated
   launcher. Plain `chrome` now uses workspace-local `.chrome` by default.
-- After code, script, or workflow changes, run the complete `task tests-run`
-  suite before handoff when the environment allows it. If the environment blocks
-  the full suite, report the blocker and list targeted checks that passed.
+- Run `task check` for normal contributor changes. Run the complete
+  `task tests-run` suite when image, Dev Containers lifecycle, Docker/Compose,
+  QEMU, browser runtime, or release-relevant integration behavior changes; if
+  the environment blocks a relevant full suite, report the blocker and targeted
+  checks that passed.
 - Runtime releases are published from clean `main` with `task release-build`;
   use `--push` only when the branch should be pushed immediately. This repository
   publishes runtime artifacts through the `release` branch only, not through
@@ -344,6 +354,7 @@
 ## Useful Commands
 
 ```bash
+task check
 task tests-run
 task qemu-alpine-smoke
 task code-open

docs/tasks/README.md

@@ -1,7 +1,8 @@
 # Task Docs
 
 This directory stores lightweight, resumable task handoff files for this
-repository.
+repository. GitHub Issues are the public discussion and tracking entrypoint;
+local task files retain implementation detail that is useful across sessions.
 
 ## Conventions
 
@@ -11,6 +12,8 @@ repository.
 - A task is represented either by a standalone markdown file or by `task.md`
   inside a task directory, never both.
 - Durable task documentation stays in English.
+- New public-facing tasks include a `Public Tracking` field. Use `pending issue
+  creation` until an Issue exists, then replace it with the Issue URL.
 
 ## Status Values
 
@@ -20,3 +23,20 @@ repository.
 - `solved` - implementation and verification are complete.
 - `finalized` - solved task has been reviewed for related docs and task state.
 - `cancelled` - task is intentionally closed without implementation.
+
+## Issue To Task To Pull Request
+
+1. Open or identify a GitHub Issue for the public problem statement.
+2. Create or update the local task specification with the Issue URL in `Public
+   Tracking`, concrete acceptance criteria, file targets, non-goals, and
+   verification.
+3. Keep task status current as the work is specified, implemented, verified, or
+   cancelled.
+4. Link both the GitHub Issue and local task path from the pull request.
+5. Let the pull request close the Issue when the accepted implementation is
+   merged; update the local task to `solved` or `finalized` in the same change
+   when appropriate.
+
+A local task may be drafted before public tracking exists, but `pending issue
+creation` means the contributor rollout is incomplete rather than privately
+tracked forever.