Release v1.2.0 with Memory Graph Phase 1 and MCP v1 rollout

Author: RichardGeorgeDavis

.github/CONTRIBUTING.md

@@ -12,6 +12,8 @@ Thanks for contributing to Codex Workspace. The repo has one concrete app surfac
 
 Start with the public contribution map in [docs/13-contributor-roadmap.md](../docs/13-contributor-roadmap.md) if you want current help-wanted areas or ready-to-open starter issue briefs.
 
+Use [docs/14-git-and-github-workflow.md](../docs/14-git-and-github-workflow.md) as the default issue, discussion, branch, and PR baseline when a repo does not already document a clearer local collaboration path.
+
 ## Small Contributions
 
 - README and docs fixes.
@@ -22,13 +24,15 @@ Start with the public contribution map in [docs/13-contributor-roadmap.md](../do
 
 ## Larger Changes
 
-Open or comment on an issue before starting:
+Open or comment on an issue before starting work in a GitHub-backed repo when the change is:
 
 - broad structural changes
 - major runtime-policy changes
 - large UI shifts in Workspace Hub
 - changes that affect workspace conventions across multiple surfaces
 
+For local-only or git-only repos, record the same scope in tracked local docs such as `README.md`, `HANDOVER.md`, or `Next Batches` instead of forcing a GitHub issue queue.
+
 ## Lightweight PR Path
 
 1. Comment on an issue or explain the focused problem in the PR.
@@ -76,6 +80,7 @@ pnpm build
 
 - Review [README.md](../README.md)
 - Review [docs/13-contributor-roadmap.md](../docs/13-contributor-roadmap.md)
+- Review [docs/14-git-and-github-workflow.md](../docs/14-git-and-github-workflow.md)
 - Start with [docs/README.md](../docs/README.md)
 - Use [GitHub Discussions Q&A](https://github.com/RichardGeorgeDavis/Codex-Workspace/discussions/categories/q-a) for setup or usage questions
 - Open an issue if the intended change affects workspace conventions

.github/ISSUE_TEMPLATE/config.yml

@@ -6,6 +6,9 @@ contact_links:
   - name: Contributor roadmap
     url: https://github.com/RichardGeorgeDavis/Codex-Workspace/blob/main/docs/13-contributor-roadmap.md
     about: See what is stable now, what is evolving next, and which contribution areas are currently in scope.
+  - name: Git and GitHub workflow baseline
+    url: https://github.com/RichardGeorgeDavis/Codex-Workspace/blob/main/docs/14-git-and-github-workflow.md
+    about: Use this when you need the default local-docs versus Discussions, Issues, and Pull Requests path.
   - name: Ask a question in Discussions
     url: https://github.com/RichardGeorgeDavis/Codex-Workspace/discussions/categories/q-a
     about: Use Discussions Q&A for setup help, usage questions, and workflow discussion.

.gitignore

@@ -26,6 +26,8 @@ tools/ref/
 tools/local/
 .cognetivy/
 .agents/
+cache/*
+!cache/.gitignore
 cache/context/
 cache/design-md/
 cache/playwright-browsers/

README.md

@@ -200,6 +200,8 @@ The practical model is:
 - local-only memory and MCP config kept separate from tracked repo content
 - a small official MCP v1 profile set for Codex, installed through workspace-owned scripts instead of ad hoc one-off setup
 
+The current MCP v1 support set is intentionally small: OpenAI Docs, Context7, Playwright, Chrome DevTools, and GitHub.
+
 This keeps context easier to inspect, reason about, and adapt across tools while keeping each repo independently runnable.
 
 Tracked repo knowledge belongs in public docs, manifests, and portable skills. Local operator memory belongs in ignored local files until it becomes stable enough to promote into tracked project guidance.

cache/.gitignore

@@ -0,0 +1,2 @@
+*
+!.gitignore

docs/09-new-repo-baseline.md

@@ -45,6 +45,16 @@ When useful, add small explicit metadata instead of hidden assumptions:
 - `.agents/skills/` only when the repo also wants a tracked compatibility mirror for workspace-native agent tooling
 - a repo-local `Next Batches` section in `README.md`, `HANDOVER.md`, or tracked `openspec/changes/.../tasks.md` when the work is large enough to need end-to-end implementation batches
 
+## Default collaboration workflow
+
+If a repo does not already define a clearer collaboration path in `README.md`, `CONTRIBUTING.md`, `AGENTS.md`, or `HANDOVER.md`, use the workspace baseline in `docs/14-git-and-github-workflow.md`.
+
+For repo intake, keep only the repo-specific implications here:
+
+- identify whether the repo is local-only, git-only, GitHub-backed, or a fork-plus-upstream case
+- prefer recording any repo-specific issue, PR, or discussion path in repo-local docs instead of restating the workspace baseline
+- do not make GitHub Projects, a uniform label taxonomy, or `gh auth login` mandatory just because a repo lives inside this workspace
+
 For public site reference copies, also prefer a short acquisition note in `README.md` or `HANDOVER.md` that records:
 
 - source URL
@@ -179,6 +189,8 @@ For a repo to feel workspace-ready, it should ideally have:
 4. a repo-local cover image path in the README, even if it begins as a placeholder
 5. enough docs that another person can resume work without guessing
 
+For GitHub-backed repos, that usually means enough repo-local docs to explain setup plus a readable issue and PR path. For local-only or git-only repos, it means the tracked local docs carry the same resumable context without pretending GitHub is required.
+
 ## Override rule
 
 If a repo has its own `AGENTS.md` or clearer local docs, those should refine this baseline rather than duplicate it.

docs/11-core-memory-and-reference-promotion.md

@@ -192,13 +192,15 @@ These wrappers should own workspace-specific path wiring and environment setup s
 
 Current wrapper coverage includes:
 
+- `workspace-memory build-graph`
 - `workspace-memory export-codex`
 - `workspace-memory mine-docs`
 - `workspace-memory mine-repo`
 - `workspace-memory mine-convos`
 - `workspace-memory split-convos`
 - `workspace-memory mine-codex`
 - `workspace-memory mine-codex-current`
+- `workspace-memory search`
 - `workspace-memory save-repo`
 - `workspace-memory save-workspace`
 
@@ -235,6 +237,41 @@ The page should show:
 - last ingest and last sync metadata
 - links to config and docs
 
+### Graph view
+
+Workspace Hub now includes a Phase 1 graph visualization flow for the selected memory target.
+
+Design rules:
+
+- MemPalace remains the source of truth for memory
+- graph artifacts are derived views, not canonical records
+- the first implementation normalizes MemPalace sidecars plus nearby markdown into a graph-ready export instead of assuming MemPalace already emits a rich graph
+- graph output should stay target-scoped for `workspace-docs`, `current-repo`, or a chosen repo
+- rebuildable graph artifacts should live under `cache/mempalace/<user>/graphs/`
+- do not introduce automatic agent-hook or `AGENTS.md` mutation as part of graph rendering
+
+Current wrapper command shape:
+
+```bash
+tools/bin/workspace-memory build-graph workspace-docs
+tools/bin/workspace-memory build-graph repo repos/workspace-hub
+```
+
+Current Hub actions are:
+
+- `Build graph`
+- `Rebuild graph`
+- `Open graph`
+- `Open graph folder`
+
+Current artifacts:
+
+- `graph.json`
+- `graph.html`
+- `graph-report.md`
+
+The repo-local design note for Workspace Hub lives at `repos/workspace-hub/docs/memory-graph.md`.
+
 ## Search and retrieval
 
 MemPalace should support workspace retrieval, but it must not replace canonical tracked docs.

docs/13-contributor-roadmap.md

@@ -8,6 +8,7 @@ The main concrete contributor surface today is [`repos/workspace-hub/`](../repos
 
 - Read [../README.md](../README.md) for the short public overview.
 - Read [../.github/CONTRIBUTING.md](../.github/CONTRIBUTING.md) for the lightweight PR path and guardrails.
+- Read [14-git-and-github-workflow.md](14-git-and-github-workflow.md) when you need the default issue, discussion, branch, and PR path for a repo that does not already document its own workflow.
 - Browse current [`help wanted`](https://github.com/RichardGeorgeDavis/Codex-Workspace/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22help%20wanted%22) and [`good first issue`](https://github.com/RichardGeorgeDavis/Codex-Workspace/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22) issues.
 - Use [GitHub Discussions Q&A](https://github.com/RichardGeorgeDavis/Codex-Workspace/discussions/categories/q-a) for setup or usage questions.
 

docs/14-git-and-github-workflow.md

@@ -0,0 +1,118 @@
+# 14-git-and-github-workflow
+
+## Purpose
+
+This note defines the default collaboration workflow for repositories inside Codex Workspace.
+
+If a repo has clearer local guidance in `README.md`, `CONTRIBUTING.md`, `AGENTS.md`, or `HANDOVER.md`, follow that repo-local guidance first.
+
+This is an advisory baseline, not a requirement to give every repo the same GitHub setup.
+
+## Baseline rule
+
+Use the lightest collaboration surface that still keeps the work understandable and resumable.
+
+- Local docs are the default fallback for repos that are local-only or do not need a public collaboration queue.
+- GitHub Issues and Pull Requests are the default path for non-trivial work in repos that actually use GitHub.
+- GitHub Discussions are useful for questions and open-ended discussion when that repo has Discussions enabled.
+- `gh` is recommended convenience tooling, not a workspace requirement.
+- `gh auth login` is optional maintainer setup, not part of the clean-clone baseline.
+
+## Repo states
+
+### Local-only
+
+Use this when a repo is not meant to be shared through GitHub or when the work is still purely local.
+
+- Track meaningful work in `README.md`, `HANDOVER.md`, or a `Next Batches` section.
+- Use a local branch when the change is risky, long-running, or easier to review as a separate slice.
+- Do not force issues or PRs where a tracked local handover is enough.
+
+### Git-only
+
+Use this when the repo is under Git but has no GitHub remote that matters for the current work.
+
+- Keep the same local tracking path as `local-only`: `README.md`, `HANDOVER.md`, or `Next Batches`.
+- Prefer small focused branches for non-trivial work.
+- Treat Git history as the reviewable surface unless the repo later adopts a GitHub queue.
+
+### GitHub-backed
+
+Use this when the repo has a GitHub remote and real collaboration happens there.
+
+- Use GitHub Discussions for setup questions, usage questions, policy questions, and open-ended design discussion when that repo has Discussions enabled.
+- If Discussions is not enabled, use Issues for actionable work and keep broader local context in tracked docs until the repo defines a better question flow.
+- Use GitHub Issues for actionable bugs, focused enhancements, docs work, and tracked follow-up tasks.
+- Use Pull Requests for non-trivial code, docs, or workflow changes that should be reviewed as a unit.
+- A tiny obvious change can still go straight to a focused PR, but non-trivial work should usually have an issue or clear written problem statement first.
+
+### Fork and upstream
+
+Use this when the repo has both a writable fork and a separate upstream remote.
+
+- Keep your working branch on the writable remote.
+- Reference upstream issues when the work is really for upstream rather than only for the fork.
+- Open the PR against the repo that should actually receive the change.
+- Only use closing keywords when the PR targets the same repo that owns the issue. Otherwise use a non-closing reference such as `Refs #123`.
+
+## Default flow for non-trivial work
+
+1. Check whether repo-local docs override this workspace baseline.
+2. Choose the tracking surface:
+   - local docs for local-only or git-only work
+   - Discussions for open-ended questions or policy discussion when the repo has Discussions enabled
+   - Issues for scoped actionable work
+3. Create a focused branch when the work is more than a tiny direct fix.
+4. Make the change, run the narrowest useful verification, and record what was checked.
+5. Close out on the matching surface:
+   - update `README.md`, `HANDOVER.md`, or `Next Batches` for local-only or git-only repos
+   - open or update a PR for GitHub-backed repos
+
+## Branch guidance
+
+These names are guidance, not enforcement.
+
+- Prefer short descriptive prefixes such as `docs/`, `fix/`, `feat/`, or `chore/`.
+- If there is an issue number, include it when helpful, for example `fix/123-preview-routing`.
+- Keep one branch focused on one reviewable outcome.
+
+## Issue, PR, and closeout guidance
+
+- Link the issue, discussion, or brief problem statement in the PR description.
+- Use closing keywords such as `Closes #123` only when merging that PR should close the issue in the same target repo.
+- Use non-closing references such as `Refs #123` when the issue lives in another repo, when the PR targets a fork first, or when more work remains.
+- Close the issue when the accepted change actually lands, not when a branch merely exists.
+- For local-only or git-only repos, record equivalent closeout context in tracked docs instead of inventing a fake issue queue.
+
+## What this baseline does not require
+
+- GitHub Projects
+- a uniform label set across every repo
+- repository rulesets beyond what an individual repo wants
+- a PR-only workflow for local-only repos
+- `gh auth login` on every machine
+
+## Common workspace scenarios
+
+### Codex Workspace root repo
+
+- Use the root issue templates, contributor guide, and PR template.
+- Route setup and usage questions toward Discussions Q&A.
+- Use issues and PRs for non-trivial workspace docs, tooling, and `workspace-hub` changes.
+
+### Normal GitHub-backed sibling repo
+
+- Use the repo's own docs first.
+- If it has no clearer collaboration doc, use this baseline: issue for scoped work, branch for implementation, PR for reviewable change, and Discussions only when that repo has them enabled.
+
+### Fork with upstream
+
+- Keep the fork writable and upstream clean.
+- Track upstream-facing work against the upstream issue when relevant.
+- Avoid accidental upstream auto-close language from fork-only PRs.
+
+### Local-only git repo
+
+- Keep the queue in tracked local docs.
+- Use branches and commits as the review surface.
+- Promote the repo to a GitHub-backed workflow only when that actually helps collaboration.

docs/CHANGELOG.md

@@ -2,6 +2,7 @@
 
 ## 2026-04-10
 
+- Bumped the workspace baseline release to `v1.2.0` and updated `repos/workspace-hub` to `1.2.0` to capture the finished MemPalace search flow, onboarding alignment, Memory Graph Phase 1, and the managed MCP v1 rollout.
 - Hardened the managed Playwright and Chrome DevTools wrappers against bad host environments where `HOME=/`, by falling back to workspace-owned runtime and npm-cache paths under `cache/` and forcing Playwright into isolated mode with a stable output directory.
 - Added the MCP v1 operating-model pack as `docs/15-mcp-profiles-and-trust-levels.md` through `docs/19-mcp-authoring-rules.md`, preserving the existing `10` through `14` docs and turning the older generic MCP note into a concrete support boundary.
 - Added tracked MCP profile and server examples under `tools/templates/mcp/`, plus repo-safe `workspace-hub` examples under `repos/workspace-hub/.workspace/mcp/`.