docs: initialize develop workflow record

This commit is contained in:
jb
2026-09-04 10:47:04 -04:00
parent b4373113a4
commit 06e631504c
+69
View File
@@ -0,0 +1,69 @@
# Develop workflow implementation record
## Status
- Status: active
- Current phase: discovery
- Next safe action: inspect repository contracts and draft the exact Slice 1-2 implementation plan.
## Request and scope
Implement the accepted plan in [`skill-led-development-workflow-plan.md`](./skill-led-development-workflow-plan.md), beginning with the production-ready skill/record contract and review/recovery integration. Scenario evaluation and the three-change pilot remain follow-on validation because they require fresh interactive sessions and real changes.
Out of scope for this change: a replacement extension, deletion or archival of the old workflow engine, global installation of extensions, pushing, publishing, deployment, and production access.
## Git identity
- Source branch: `main`
- Base commit: `27cbe965bbd3dc0ca38814811b4f56519a570957`
- Feature branch: `feature/develop-workflow`
- Worktree: `/srv/data/code/jb-pi/harness-tools/.worktrees/develop-workflow`
- Omitted source change: uncommitted YAML quoting in `skills/document/artifact-presenter/SKILL.md`; user approved omission.
## Acceptance criteria
- Add the model-invoked `develop-workflow` skill, progressive references, record template, atomic checkpoint script, and focused failure-path tests without dependencies.
- Expose the skill through the repository-managed Pi link policy while keeping the old workflow extension unexposed.
- Supersede stale workflow documentation with a concise ADR and explicit historical pointers.
- Align `code-review`, `implement`, `prototype`, artifact presentation, task tracking, reviewer independence, recovery, and local integration contracts.
- Pass focused checkpoint tests, link checks, documentation checks where available, typecheck, and the repository test suite.
- Obtain independent standards and specification approval over a pinned, fingerprinted product diff before local integration.
## Approved implementation plan and gates
- Specification: [`skill-led-development-workflow-plan.md`](./skill-led-development-workflow-plan.md), status Accepted.
- Plan gate: approved by the user on 03SEP2026 with “let's implement”.
- Dirty-source gate: approved on 03SEP2026; proceed while omitting the unrelated source-checkout change.
- UI classification: no product UI change; prototype direction gate does not apply.
- Risk gates: none currently identified. Ask immediately before any newly discovered risky action.
## Ownership
The parent agent owns orchestration and this record. Mutating assignment ownership and deadlines will be recorded after discovery and before production edits.
## Verification matrix
| Surface | Command | Outcome |
| --- | --- | --- |
| Checkpoint helper | `node --test skills/develop/develop-workflow/tests/checkpoint-record.test.mjs` | Pending |
| Managed links | `node --test scripts/pi-links.test.mjs` and `./scripts/pi-links.mjs check` | Pending |
| TypeScript | `bun run typecheck` | Pending |
| Full repository | `bun test` | Pending |
## Review
- Fixed point: pending final synchronization.
- Specification source: this record and the accepted skill-led workflow plan.
- Mutators: parent agent; additional implementers pending.
- Standards reviewer: pending, must be read-only and independent.
- Specification reviewer: pending, must be read-only and independent.
- Diff fingerprint and findings: pending.
## Integration and rollback
Rebase the feature branch onto the latest local/remote `main` when available, rerun verification, independently review the exact diff, then fast-forward local `main`. Roll back before integration by deleting the isolated feature branch only after separate evidence and approval; after integration, revert focused commits rather than rewriting shared history.
## Checkpoints and blockers
- Initial record created before product mutation.
- The source checkout remains dirty with the explicitly omitted artifact-presenter change. Automatic final integration is blocked until the source checkout is clean or the user authorizes an evidence-backed alternative.