k-harness 0.9.1 → 0.9.2

package/harness/agents/planner.md

@@ -134,3 +134,19 @@ Apply these insights when creating the implementation plan. If the memory file i
 - All plans must include test tasks (no code without tests)
 - If a feature affects 5+ modules, flag as High Risk
 - If the plan exceeds one Sprint's worth of work, suggest splitting into sub-features
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Planning
+
+### Pre-Pull
+Before reading or updating shared state files, run `git pull origin main`.
+
+### Owner-Aware Planning
+- When assigning tasks, check docs/dependency-map.md Owner column to identify module ownership
+- For features that cross module boundaries, identify all affected Owners and flag coordination needs
+- Set Owner on new rows you create in docs/features.md and docs/dependency-map.md
+
+### Agent Memory
+- Your personal docs/agent-memory/planner.md contains your individual estimation accuracy
+- Team velocity estimates should be coordinated through sprint planning meetings, not derived from personal metrics alone
+<!-- TEAM_MODE_END -->

package/harness/agents/reviewer.md

@@ -157,3 +157,19 @@ When Step 8 (State File Audit) produces `[STATE-AUDIT]` flags:
 1. List all flagged items in the review output
 2. The `learn` skill (run at session end) will verify and resolve these flags
 3. If a flag is critical (missing module in dependency-map, unregistered feature), recommend fixing immediately rather than deferring to learn
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Review
+
+### Pre-Pull
+Before running review, run `git pull origin main` to get the latest shared state files.
+
+### Owner-Scoped Audit
+- **Step 6 (Feature Registry)**: only check that YOUR new features are registered — do not modify other developers' rows
+- **Step 7 (Dependency Map)**: only check that YOUR new modules are registered — do not modify other developers' rows
+- **Step 8 (State File Audit)**: verify that personal state files (docs/project-state.md, docs/failure-patterns.md, docs/agent-memory/) are updated; for shared files, only audit your own Owner rows
+
+### Cross-Owner Changes
+- If your changes affect modules owned by other developers (check docs/dependency-map.md Owner), flag these as "⚠️ Cross-Owner Impact" in the review output
+- Recommend getting the affected Owner's review before merging
+<!-- TEAM_MODE_END -->

package/harness/agents/sprint-manager.md

@@ -136,3 +136,20 @@ STATUS: DONE
 ## Related Failure Patterns
 
 - FP-003: Scope drift → Scope Check handler detects out-of-scope modifications and warns the user before proceeding
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Sprint Management
+
+### Personal vs Shared State
+- Your sprint progress is tracked in personal docs/project-state.md
+- Shared docs/features.md and docs/dependency-map.md reflect the entire team's work
+- When reporting status, read BOTH personal and shared state for a complete picture
+
+### Scope Check with Ownership
+- When checking scope, also verify the module's Owner in docs/dependency-map.md
+- If work is being done on a module owned by another developer, flag it as a potential scope drift AND an ownership concern
+
+### Next Step Recommendation
+- Consider other developers' active stories when recommending next steps
+- If a dependency on another developer's work is detected, recommend coordination before proceeding
+<!-- TEAM_MODE_END -->

package/harness/skills/bootstrap.md

@@ -163,3 +163,27 @@ When starting a NEW session (not during bootstrap), read these files in order:
 | Leave rules file TODOs unfilled | Phase 3.5 fills ALL TODO sections — no manual editing needed |
 | Use TypeScript globs for non-TS projects | Detect language in Phase 1 and set correct globs |
 | Only fill state files, skip rules | Bootstrap fills BOTH — state files AND rules files |
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Onboarding
+
+When running bootstrap in Team mode:
+
+### New Project (first developer)
+1. Run `k-harness init --team` to create shared + personal state files
+2. Fill all state files via normal bootstrap procedure
+3. Commit shared files (docs/) to git
+4. Push to remote — teammates will clone this
+
+### Joining Developer (existing project)
+1. Clone the repository (shared docs/ already exist)
+2. Run `k-harness init --team` — only personal files (.harness/) are created; shared files are skipped
+3. **DO NOT re-run bootstrap interviews** — shared state is already filled by the first developer
+4. Review docs/project-brief.md to understand project goals
+5. Create your personal .harness/project-state.md with your current Story assignment
+
+### Rules
+- **Never overwrite shared files** when joining an existing project
+- Set your Owner name in docs/features.md and docs/dependency-map.md rows you create
+- Personal state (.harness/) is yours alone — no coordination needed
+<!-- TEAM_MODE_END -->

package/harness/skills/feature-breakdown.md

@@ -99,3 +99,20 @@ After completing the breakdown, update these files in the same session:
 - FP-001: Interface changed, mock not updated → When creating tasks that modify interfaces, include "Update mock" as an explicit sub-task
 - FP-002: Type confusion → When annotating tasks, specify expected types for new interfaces
 - FP-003: Scope drift → If the breakdown exceeds the current Story scope, stop and report
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Feature Breakdown
+
+### Pre-Pull
+Before updating shared state files, run `git pull origin main` to get the latest docs/features.md and docs/dependency-map.md.
+
+### Owner Assignment
+- When adding new rows to docs/features.md, set the Owner column to your name
+- When adding new modules to docs/dependency-map.md, set the Owner column to your name
+- Do NOT modify rows owned by other developers — if there is a dependency, note it in your task description instead
+
+### Cross-Developer Dependencies
+If your feature depends on a module owned by another developer:
+1. Note the dependency in the task description (e.g., "Depends on [module] owned by [dev]")
+2. Coordinate with the module owner before implementation
+<!-- TEAM_MODE_END -->

package/harness/skills/impact-analysis.md

@@ -78,3 +78,16 @@ After completing the analysis, update these files:
 
 - FP-001: Interface changed, mock not updated → Checklist item 7 (mock/test updates planned)
 - FP-002: Type confusion across modules → Step 7 (trace each dependent, verify types)
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Impact Analysis
+
+### Owner-Aware Blast Radius
+- When listing affected modules from docs/dependency-map.md, check the Owner column
+- If a dependent module is owned by another developer, the blast radius extends to their scope
+- Flag cross-owner impacts: "⚠️ Module [X] owned by [dev] will be affected"
+
+### Notification
+- For interface changes affecting modules owned by other developers, **list them explicitly** in the analysis output
+- Recommend notifying affected module owners before proceeding with changes
+<!-- TEAM_MODE_END -->

package/harness/skills/investigate.md

@@ -89,3 +89,16 @@ After the fix is verified (Phase 4):
 - FP-001: Mock not updated → Phase 4 requires checking mock sync
 - FP-002: Type confusion → Phase 1 requires verifying actual types
 - FP-003: Scope drift → Phase 2 Scope Lock must verify fix is within current Story scope
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Investigation
+
+### Owner Awareness
+- In Phase 2 (Scope Lock), check docs/dependency-map.md Owner column for the affected module
+- If the root cause module is owned by another developer, **notify them** before applying a fix
+- If the bug is in a shared module (no single Owner), document the fix in your PR description so the team can review
+
+### Personal State
+- Record new failure patterns in your personal .harness/failure-patterns.md
+- If the pattern affects the whole team, promote it (see learn skill Team Mode section)
+<!-- TEAM_MODE_END -->

package/harness/skills/learn.md

@@ -144,3 +144,21 @@ STATUS: DONE
 | Write vague descriptions ("something broke") | Be specific: file name, error message, root cause |
 | Skip this skill because "nothing went wrong" | Still update Quick Summary and Story Status |
 | Update docs/failure-patterns.md but not docs/project-state.md | Always update both — they serve different purposes |
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Session Wrap-up
+
+### Pre-Pull (mandatory before any shared file edit)
+1. Run `git pull origin main` before updating docs/features.md or docs/dependency-map.md
+2. If merge conflicts occur, resolve them BEFORE proceeding
+
+### Owner-Scoped Updates
+- **docs/features.md**: only update rows where Owner = you
+- **docs/dependency-map.md**: only update rows where Owner = you; if adding a new module, append at the bottom
+- **Personal files** (.harness/project-state.md, .harness/failure-patterns.md, .harness/agent-memory/): update freely — no coordination needed
+
+### Failure Pattern Promotion
+If a personal failure pattern (FP-NNN in .harness/failure-patterns.md) is likely to affect other developers:
+1. Discuss with the team (Slack, PR comment, etc.)
+2. If agreed, add it to a shared location (team wiki, PR description) so others can add it to their personal .harness/failure-patterns.md
+<!-- TEAM_MODE_END -->

package/harness/skills/pivot.md

@@ -113,3 +113,22 @@ If `.harness/` directory exists (Team mode is active):
   3. Team lead runs pivot on main
   4. All developers pull main to get updated shared state files
   5. Each developer's `.harness/` personal state is unaffected (update manually if needed)
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Pivot Lock
+
+### Who Can Run Pivot
+- **Only the team lead** runs pivot, and **only on the main branch**
+- If you are not the team lead, propose the direction change to the team lead instead of running pivot yourself
+
+### Branch Check
+Before running pivot, verify:
+1. You are on the `main` branch: `git branch --show-current` must return `main`
+2. Your working tree is clean: `git status` must show no uncommitted changes
+3. You have pulled the latest: `git pull origin main`
+
+### After Pivot
+1. Commit and push the updated shared files
+2. Notify all team members to run `git pull origin main`
+3. Each developer's personal .harness/ files are NOT auto-updated — developers should review the pivot changes and manually update their personal state if needed
+<!-- TEAM_MODE_END -->

package/harness/skills/security-checklist.md

@@ -60,3 +60,11 @@ After completing the security check:
 ## Related Failure Patterns
 
 - FP-004: Dangerous file committed → Checklist items 2, 5 (no forbidden files, no temp files)
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Security
+
+- Personal state files (.harness/) are gitignored — they cannot leak via git
+- When committing shared config files (docs/), verify no team credentials or shared secrets are included
+- If a security issue is found in a shared module, notify the module Owner before fixing
+<!-- TEAM_MODE_END -->

package/harness/skills/test-integrity.md

@@ -68,3 +68,10 @@ After synchronizing mocks:
 
 - FP-001: Interface changed, mock not updated → Checklist item 2
 - FP-002: Type confusion → Step 5 return type verification
+
+<!-- TEAM_MODE_START -->
+## Team Mode: Test Integrity
+
+- If the interface you changed is owned by another developer (check docs/dependency-map.md Owner), notify them about the mock update requirement
+- When updating shared test fixtures or mocks, run `git pull` first to avoid overwriting teammates' changes
+<!-- TEAM_MODE_END -->

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "k-harness",
-  "version": "0.9.1",
+  "version": "0.9.2",
   "description": "LLM Development Harness — IDE-agnostic rules, skills, and agents that prevent common AI coding failures",
   "keywords": [
     "llm",

package/src/init.js

@@ -75,19 +75,31 @@ This project uses Team mode. State files are split into shared and personal.
 - **Personal** (.harness/, gitignored): project-state.md, failure-patterns.md, agent-memory/
 
 ### Rules
-1. Shared files: only modify your own rows (check Owner column)
-2. Other developers' Owner rows are READ ONLY
-3. New rows go at the bottom of the table
-4. The \`pivot\` skill must be run on the main branch by the team lead only
+1. **Pre-Pull**: before modifying any shared file (docs/), run \`git pull\` to get latest changes
+2. **Owner Column**: shared files use Owner columns — only modify your own rows
+3. **Read-Only**: other developers' Owner rows are READ ONLY
+4. **Append-Only**: new rows go at the bottom of the table
+5. **Pivot Lock**: the \`pivot\` skill must be run on the main branch by the team lead only
+6. **FP Promotion**: if a personal failure pattern (FP-NNN) affects the team, promote it to a shared doc or team channel
 `;
 
 function resolveContent(content, mode) {
-  if (mode !== 'team') return content;
+  if (mode !== 'team') {
+    // Solo mode: strip Team-only blocks entirely
+    return content.replace(/<!-- TEAM_MODE_START -->[\s\S]*?<!-- TEAM_MODE_END -->\n?/g, '');
+  }
   let result = content
     .replaceAll('docs/project-state.md', '.harness/project-state.md')
     .replaceAll('docs/failure-patterns.md', '.harness/failure-patterns.md')
     .replaceAll('docs/agent-memory/', '.harness/agent-memory/');
 
+  // Remove markers, keep Team content
+  result = result
+    .replaceAll('<!-- TEAM_MODE_START -->\n', '')
+    .replaceAll('<!-- TEAM_MODE_START -->', '')
+    .replaceAll('<!-- TEAM_MODE_END -->\n', '')
+    .replaceAll('<!-- TEAM_MODE_END -->', '');
+
   // Append Team Mode section to core-rules (detected by the heading)
   if (result.includes('## State Files') && result.includes('## Session Start')) {
     result += TEAM_MODE_SECTION;