docs(account): explain repository model

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,7 +1,7 @@
 ## Tracking
 
 - Repository Issue: <!-- Link the Issue in the repository that owns this change. -->
-- Canonical task or exception: <!-- Link docs/tasks/.../task.md. Only for a tiny policy/profile/docs fix in .github or codegeist-ai/codegeist-ai, write "No local task needed: <reason>". -->
+- Canonical task or exception: <!-- Link the applicable task under docs/tasks/. If the owning repository's guide permits no new task, write "No local task needed: <maintainer-approved reason>". -->
 
 ## Summary
 
@@ -14,7 +14,7 @@
 ## Impact Checklist
 
 - [ ] I did not include credentials, tokens, sensitive configuration, or private security details.
-- [ ] I linked the canonical task, or this is an eligible `.github` or `codegeist-ai/codegeist-ai` fix and I explained why no local task is needed.
+- [ ] I linked the applicable canonical task, or the owning repository permits no new task and I recorded the maintainer-approved reason.
 - [ ] I assessed security implications and used private reporting where required.
 - [ ] I assessed whether documentation, tests, or repository-specific checks need updates.
 - [ ] I assessed whether a generated `release` branch needs an update.

CONTRIBUTING.md

@@ -4,36 +4,43 @@ Thank you for improving Codegeist. This guide is the account-wide default;
 instructions in the target repository take precedence when they are more
 specific.
 
+Read the [GitHub account and repository model](GITHUB_ACCOUNT_MODEL.md) when you
+are unsure which repository owns a change or why the two account infrastructure
+repositories exist.
+
 ## Workflow
 
-Source-repository implementation work follows one traceable path:
+Ready source-repository implementation work follows one traceable path:
 
 ```text
-Project -> repository Issue -> repository docs/tasks/.../task.md -> branch -> PR -> merge
+Project -> repository Issue -> canonical repository task -> branch -> PR -> merge
 ```
 
 1. Use the [public roadmap](https://github.com/users/codegeist-ai/projects/1) to
    understand priority and status.
 2. Open or select an Issue in the repository that owns the change. Keep the
    Issue focused on the user-visible problem, outcome, and public discussion.
-3. Link the Issue to its ready canonical `docs/tasks/.../task.md` before
-   implementation begins. The task records acceptance criteria, file targets,
-   and verification details close to the code.
+3. Before the Issue is marked `status:ready`, link it to its canonical task under
+   `docs/tasks/`. The task may use the repository's flat or nested task form and
+   records acceptance criteria, file targets, and verification details close to
+   the code.
 4. Create a small branch from the current `main`, implement the task, and run
    the target repository's documented checks.
 5. Open a pull request that links the Issue and task, explains the result, and
    reports verification.
 6. Merge only after review and all checks required by that repository pass.
 
 The roadmap is the public view of priorities, an Issue is the repository-level
-unit of discussion, and a task file is the implementation contract. Source
-implementation in `codegeist` or either shared kit requires all three links.
+unit of discussion, and a task file is the implementation contract. Source work
+advertised as ready in `codegeist` or either shared kit requires all three links.
+For a small unplanned fix, follow the owning repository's local guide to determine
+whether maintainers require a new task before the pull request. Always link an
+existing task when one already defines the work.
 
 A tiny policy, profile, or documentation-only fix in `.github` or
 `codegeist-ai/codegeist-ai` may omit a local task. Its pull request must still
 link a repository Issue and state `No local task needed:` followed by a brief
-reason. Existing tasks must always be linked; this exception does not apply to
-source-repository implementation work.
+reason. Existing tasks must always be linked.
 
 ## Forks, Branches, And Pull Requests
 
@@ -42,9 +49,10 @@ source-repository implementation work.
 - Contributors with write access may use a branch in the target repository.
 - Keep branches focused and up to date. Do not mix unrelated fixes.
 - Explain behavior changes and update relevant documentation and tests.
-- Link the repository Issue and canonical task in every source implementation
-  pull request. Use the documented no-task exception only in the two account
-  infrastructure repositories.
+- Link the repository Issue in every source pull request. Link the canonical task
+  whenever the Issue is ready or an existing task defines the work. If the owning
+  repository's local guide permits a small unplanned fix without a new task, state
+  `No local task needed:` and the maintainer-approved reason in the pull request.
 
 There is no single account-wide build command. Each repository documents its
 normal local check in its README, contribution guide, task file, or automation

FUTURE_REPOSITORY_CHECKLIST.md

@@ -2,7 +2,9 @@
 
 Use this baseline when creating or opening another public repository under
 `codegeist-ai`. Check inherited defaults as well as files stored directly in the
-new repository.
+new repository. Read [`GITHUB_ACCOUNT_MODEL.md`](GITHUB_ACCOUNT_MODEL.md) first so
+the new repository fits the existing ownership, planning, release, and policy
+model.
 
 ## Purpose And Ownership
 
@@ -18,6 +20,9 @@ new repository.
 - [ ] Confirm that effective contribution, conduct, security, support, Issue,
   and pull request files come from `codegeist-ai/.github` or deliberate local
   overrides.
+- [ ] If any local `.github/ISSUE_TEMPLATE/` file is added, copy or recreate every
+  shared form and contact link that should remain available because GitHub stops
+  inheriting the entire default issue-template directory.
 - [ ] Document one normal local check that contributors can run before a pull
   request.
 - [ ] Document the local `docs/tasks/.../task.md` format and how tasks link to