forgedock 1.0.9 → 1.0.11

package/commands/work-on.md

@@ -745,6 +745,8 @@ if iteration == max_iterations AND not PASS:
 
 **After quality gate completes (PASS or fixes applied): proceed immediately to sub-phase 3H below. Quality gate is an intermediate check — "PASS" means the code is clean, NOT that the build is done. Do NOT stop.**
 
+**After PASS: Do NOT re-read GitHub state, issue body, labels, or any file. Do NOT run any gh commands. Do NOT check PR status. Proceed directly to Phase 3H (Format and verify) below.** <!-- Added: forge#93 -->
+
 ### 3H: Format and verify
 
 All tool commands are read from `forge.yaml → verification.commands`. When a key is absent, the step logs `SKIPPED — not configured in verification.commands` and continues rather than silently passing.
@@ -999,10 +1001,25 @@ PR #${PR_NUMBER} created targeting \`{PR_BASE}\`. Invoking /review-pr with --aut
 ```
 
 ### 5C: Invoke /review-pr with --auto-merge
+
+**Context budget check** (run before invoking review-pr): <!-- Added: forge#93 -->
+
+Large-context sessions that accumulated significant build history cause review-pr to hit the token limit mid-review. Check the accumulated context before delegating:
+
+- If the build changed **≥10 files** OR this agent has made **≥20 Skill invocations** since it started: invoke `work-on/review` as a fresh sub-agent (via `Skill(skill="work-on/review", args="...")`) rather than calling review-pr directly. The sub-agent starts with a clean context window.
+- Otherwise (small build, few skill calls): invoke review-pr directly as below.
+- **Fallback**: if `work-on/review` is not available (partial install), invoke review-pr directly regardless of file count and add a note that context may be large.
+
+**Direct invocation** (small builds — <10 changed files AND <20 Skill invocations):
 ```
 Skill(skill="review-pr", args="{PR_NUMBER} --auto-merge --issue {NUMBER} --base {PR_BASE} --gh-flag {GH_FLAG}")
 ```
 
+**Sub-agent invocation** (large builds — ≥10 changed files OR ≥20 Skill invocations):
+```
+Skill(skill="work-on/review", args="{NUMBER} --repo {GH_REPO} --gh-flag {GH_FLAG} --worktree {WORKTREE_PATH} --branch {BRANCH} --base {PR_BASE}")
+```
+
 Review-pr handles: full domain-agent review → post findings as separate issues → merge PR. It does NOT close the issue or clean up the worktree — those run in Phase 6.
 
 ### 5D: Verify merge and close (recovery)
@@ -1020,6 +1037,8 @@ gh issue view {NUMBER} {GH_FLAG} --json state --jq '.state'
 
 **After /review-pr returns and the PR is confirmed merged: immediately proceed to Phase 6 (Close & Cleanup). Do NOT stop here. `REVIEW_RESULT: status: COMPLETE` is an intermediate result — the pipeline is NOT done. Invoke Phase 6 now to close the issue, update labels, post the trajectory log, and clean up the worktree.**
 
+**Do NOT output any text describing this transition. Do NOT write phrases like "returning to work-on", "proceeding to close", "now invoking Phase 6", or any narrative summary of what comes next. Do NOT emit end_turn. Execute Phase 6 code immediately.** <!-- Added: forge#93 -->
+
 ---
 
 ## Phase 6: Close & Cleanup

package/docs/CONFIG.md

@@ -472,6 +472,25 @@ Colors are grouped by semantic meaning:
 
 ---
 
+## `marketing` (OPTIONAL)
+
+Controls opt-in growth features such as 'Powered by ForgeDock' footers on PR descriptions created by the pipeline.
+
+> **Note**: `pr_footer` injection requires future pipeline support in `/work-on`. Setting `pr_footer: true` today has no effect — it is a configuration interface that will be activated when the feature ships. When implemented, the pipeline will append a one-line footer to every PR body it creates.
+
+```yaml
+marketing:
+  pr_footer: false
+```
+
+| Field | Type | Required | Default | Description |
+|-------|------|----------|---------|-------------|
+| `pr_footer` | boolean | No | `false` | When `true`, the pipeline appends a 'Powered by ForgeDock' footer link to every PR description it creates. Opt-in only — non-intrusive one-line footer, not a banner. Requires pipeline support (not yet implemented). |
+
+**Commands that use this section**: `work-on` (Phase 4 PR creation — when `pr_footer: true`)
+
+---
+
 ## Config Reading Conventions
 
 ForgeDock commands use two accepted patterns for reading `forge.yaml`:
@@ -665,6 +684,24 @@ The `registry` module resolves one of three states for any directory:
 
 A missing or corrupt `registry.json` is treated as an empty opt-out set. The registry always fails open — it never throws and never blocks a Claude Code session.
 
+### Downgrade Behaviour
+
+Registry keys are the **real path** of a directory (resolved via `realpathSync`) rather than the raw `resolve()` path. This has been the case since v1.0.x (PR #467, which fixed symlinked-directory key mismatches).
+
+If you downgrade to a build older than PR #467 **and** your project is accessed via a symlinked directory path, the older build looks up registry entries using the pre-symlink `resolve()`-only key form. It will not find entries written by the newer build's real-path keys. The practical effect is benign:
+
+- Opt-outs set on the newer build briefly stop applying for one session.
+- The one-time "Enable ForgeDock here?" nudge may reappear once.
+- No data is lost. No crash. Fail-open behaviour holds throughout.
+
+**Recovery**: after downgrading, re-apply your opt-out with the older build:
+
+```bash
+npx forgedock disable [dir]
+```
+
+This re-writes the entry under the key form the older build expects.
+
 ### Managing Opt-Out State
 
 Use the `forgedock enable` and `forgedock disable` commands to add or remove a directory from the opt-out set: