docs(captain): crew threads ask their Captain for new threads (R68); capy read is a view

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

capy/skill/gstack/SKILL.md

@@ -81,6 +81,7 @@ In a repository with a sealed configuration (a `sealed` key in its `.gstack/preg
 - Use Capy's user-visible messaging and question tools for output and decisions. Plain assistant text is not a delivered message in Capy. Use Capy's task and pull-request workflows rather than unavailable Claude or Codex host tools.
 - Capy has no native gstack host target. Claude hooks do not become enforced Capy hooks; safety skills are advisory here, and `/autoplan` prints `autoplan guard: not enforced by this host` once to say so. Report missing capabilities instead of silently claiming equivalent enforcement.
 - Selecting GPT-6 Astra or Claude in Capy does not install or authenticate the Codex or Claude Code CLI. For cross-model reviews, a subagent on another model family is a full outside voice; record the model that reviewed. Do not report a missing Codex CLI as degraded coverage when another runner reviewed.
+- `tools.capy.read` returns a view, not the whole file: about the first 38,000 characters, each line cut at 2,000. A read, change and `tools.capy.write` program therefore saves a truncated file, Drive files included. Edit long files with `tools.capy.edit`, or read and write the whole file in bash or Python and check the line count afterward; `tools.drive.history` restores a recent version.
 - Preserve the user's requested scope, decisions, and consent. Do not enable telemetry or remote artifact sharing on their behalf. Installing gstack does not authorize merging, deploying, destructive operations, or bypassing approvals.
 
 ## Maintenance

capy/skill/gstack/factory.md

@@ -13,5 +13,5 @@ What seven Captain crews agreed on. Your crew's CREW.md and recorded approvals d
 9. **Flakes: one rerun, a ledger, a daily fix.** Only the policy's rerun, never for a harness or infra red; a second red is real; never loosen a test. [docs/captain.md: The daily flaky pass]
 10. **Quiet.** Message on a decision, a blocker, a READY or a finished phase. A broadcast needing no reply goes in the Captain's notes; never reply just to acknowledge.
 11. **Ask once, plainly.** One ask per decision, explained like the owner is five: your Captain's name, then a lettered line each: "A: <code> hit problem p, which happens when h. We could do 1) x, 2) y or 3) z. Recommendation x because why. A1 to take recommendation." "do it" takes every recommendation; "A2" takes option 2. Owner tasks: the exact link (in Capy: path and field), numbered steps, the reply word. Never re-ask a standing rule; check what you can yourself. [docs/captain.md: The ask format]
-12. **Fresh threads, closed out.** One thread per unit of work (crew threads ask their Captain); past the context limit, hand off. Its Captain archives only its crew's threads; threads outside every crew are the owner's, even its automation's. Size reviews to the diff; read the token counter. [docs/ship-budget.md]
+12. **Fresh threads, closed out.** One thread per unit of work; past the context limit, hand off. Crew threads never create threads: ask your Captain (Captain to Captain for another project), or report one you made by code for crew.add. Its Captain archives only its crew's threads; threads outside every crew are the owner's, even its automation's. Size reviews to the diff; read the token counter. [docs/ship-budget.md; docs/captain.md: New threads join the crew]
 13. **The owner's model preference.** `gstack-models resolve --role agent` picks agent models, except cross-family voices and eval subjects. [docs/model-policy.md: Your model preference]

changelog.d/garrytan-r68-crew-threads-attach.md

@@ -0,0 +1,6 @@
+**A crew thread no longer creates threads itself. It asks its Captain, so every new thread joins a crew from the start (R68). The Capy skill also warns that `tools.capy.read` returns a cut-down view of long files.**
+
+### Changed
+- **docs/captain.md** has a new section, "New threads join the crew". A crew thread asks its Captain for a new thread, and the Captain creates it in the crew. A thread the crew thread already made gets reported by code in that turn, so the Captain can add it with `crew.add`. A thread in another project goes Captain to Captain: the receiving Captain creates it in its own crew as work, briefs it and returns the result. Only a project with no Captain lets the crew thread create the thread itself, with the code recorded on the work's issue. The cause: GBRA-240 created GBEV-33 directly in another project, and that thread ran outside every crew.
+- **The Capy factory context (`factory.md` point 12)** now has the short version and cites that section. Its byte budget in `test/capy-skill-wrapper.test.ts` goes from 3,300 to 3,450: the page's new size rounded up to the next 25 bytes, and no other point was trimmed.
+- **The Capy skill's host adaptations** say that `tools.capy.read` returns about the first 38,000 characters, with each line cut at 2,000. So a read, change and `tools.capy.write` program saves a truncated file, Drive files included. Edit long files with `tools.capy.edit`, or read and write the whole file in bash or Python and check the line count. `tools.drive.history` restores a recent version. This is how the org knowledge base's rules.md lost 37 rules.

docs/captain.md

@@ -131,6 +131,25 @@ such decision with a plain-language explanation of every option: what it is, why
 matters, what each answer does, and what it costs. A gate code or a tool's result line
 alone is not an ask.
 
+## New threads join the crew
+
+A crew thread never creates a thread itself. It asks its Captain, and the Captain creates
+the thread, which puts it in the crew from the start: the Captain briefs it, reads its
+reports and archives it when its work is done. When a crew thread has already made a
+thread, it reports the new thread's code to its Captain in that same turn, and the Captain
+adds it to the crew (`crew.add` on Capy).
+
+A thread in another project goes Captain to Captain, because `crew.add` refuses a thread
+from another project and a Captain creates threads only in its own project. The crew
+thread asks its Captain, who asks that project's Captain to create and own the thread, and
+the results come back the same way. For the receiving Captain, that ask is work: it
+creates the thread in its own crew, briefs it and returns the result. Only when the other
+project has no Captain does the crew thread create the thread itself, and then it records
+the new thread's code on the work's issue so the thread can still be found.
+
+Why: a crew thread once created a thread in another project directly. That thread ran
+outside every crew, so no Captain briefed it, tracked it or could archive it.
+
 ## Plan before build
 
 A lane that builds something plans first. Its first act after the session-start install

test/capy-skill-wrapper.test.ts

@@ -587,9 +587,11 @@ describe('capy skill: factory.md, the auto-loaded "how we work" page', () => {
     return [...new Set(problems)];
   }
 
-  test('it fits the 3,300-byte budget, and every citation, heading and skill it names resolves', () => {
+  test('it fits the 3,450-byte budget, and every citation, heading and skill it names resolves', () => {
     const text = fs.readFileSync(FACTORY, 'utf8');
-    expect(Buffer.byteLength(text)).toBeLessThanOrEqual(3300);
+    // 3,300 since #3634; raised to 3,450 (the page's new size, rounded up to the next 25 bytes) for point 12's
+    // R68 clause (Garry, 2026-11-03: crew threads ask their Captain for new threads). Raise it only by what a rule needs.
+    expect(Buffer.byteLength(text)).toBeLessThanOrEqual(3450);
     expect(text).toMatch(/^# How we work/);
     expect(citationProblems(text)).toEqual([]);
   });