refactor: rename workflow service files

[devkade]

Summary

• Renames the application service implementation files from kapi-* filenames to semantic workflow-service paths.
• Updates source, tests, docs, and autoresearch runtime probes to import the new service paths.
• Extends the architecture filename guard and product-name audit residual scan.

Linked issue

Refs #209

Problem

Issue #209 tracks removal of historical kapi product-name leakage from reusable internal code while preserving intentional compatibility/product surfaces.

After PR #210, the remaining non-fixture src/ filename leakage included the application service boundary:

src/application/kapi-service.ts
src/adapters/kapi-service-factory.ts

Those files implement generic workflow service/factory behavior. Keeping kapi in their filenames made the service boundary look product-specific even though the runtime direction is semantic internal naming.

Options considered

1. Rename filenames and exported symbols together — KapiService → WorkflowService, FileKapiStore → follow-up store names, and factory function names in one PR.
   • Pros: larger visible cleanup.
   • Cons: many more call sites and compatibility risk; likely too large for the review-size gate.
2. Rename only service/factory filenames and import paths — leave exported names for a focused compatibility/export slice.
   • Pros: small, reviewable, removes the filename leakage safely, and keeps runtime/API behavior unchanged.
   • Cons: KapiService, createLocalKapiService, and store-related identifiers remain for later work.
3. Skip service files and move directly to kapi-review-cli.
   • Pros: leaves service imports untouched.
   • Cons: kapi-review is an intentional external integration name, while service filenames were generic implementation leakage.

Selected approach

Selected option 2.

This PR handles only the application service filename/import boundary. It does not rename exported classes/functions yet, because those names have many test/source consumers and should be handled as a separate compatibility slice.

Implementation by file/surface

• src/application/kapi-service.ts → src/application/workflow-service.ts
  • Moved the generic workflow service implementation to a semantic filename.
  • Updated all source/test imports to the new path.
• src/adapters/kapi-service-factory.ts → src/adapters/workflow-service-factory.ts
  • Moved the local service factory to a semantic adapter filename.
  • Updated Pi extension and test imports.
• autoresearch.sh
  • Updated runtime probe imports to ./src/application/workflow-service.ts.
  • Updated the source-corpus filter from kapi-service to workflow-service so autoresearch metrics still include the renamed service.
• test/architecture.test.ts
  • Extended the filename guard to assert old service filenames are absent and semantic workflow-service filenames exist.
• docs/product-name-audit.md and docs/harness-module-registry.md
  • Updated the residual scan and service-source references.

Why this fixes it

The service implementation can no longer be imported through kapi-service paths. The architecture guard now fails if the old application/factory filenames reappear, and the residual filename scan is reduced to fixture/history plus the intentional external kapi-review CLI.

This is still a partial #209 slice, so this PR uses Refs #209 rather than Closes #209.

QA / Verification

• npm test -- test/architecture.test.ts test/service-store.test.ts test/deep-interview-child-rpc.test.ts test/presentation-command-behavior.test.ts — pass; package script ran the full suite, 519 tests, 508 pass, 11 skipped.
• npm run check — pass.
• npm run check:unused — pass.
• npm run quality:budgets — pass with existing non-failing code_smells=52 warning.
• git diff --check — pass.

Residual scans:

find src -iname '*kapi*' -print
src/.kapi
src/.kapi/lanes/kapi-autoresearch
src/.kapi/lanes/kapi-autoresearch/kapi-ux-개선-계획
src/cli/kapi-review-cli.ts

rg -n 'kapi-service|kapi-service-factory|application/kapi-service|adapters/kapi-service-factory' . --glob '!node_modules/**' --glob '!package-lock.json'
test/architecture.test.ts:41:  assert.equal(files.includes(path.join("src", "application", "kapi-service.ts")), false);
test/architecture.test.ts:42:  assert.equal(files.includes(path.join("src", "adapters", "kapi-service-factory.ts")), false);

Changed-line count:

git diff --shortstat origin/dev...HEAD
38 files changed, 73 insertions(+), 69 deletions(-)

Independent review:

• Static/security scan — no hardcoded secrets, shell injection, eval/exec, unsafe deserialization, or SQL injection findings.
• Independent reviewer subagent — initial review caught stale autoresearch.sh imports; fixed and re-reviewed successfully.

Anomalies observed

Symptom	Evidence	Impact	Action
Targeted-looking npm test -- <files> runs the full suite because the package script is tsx --test test/*.test.ts.	Test output showed 519 tests.	QA was broader than the named files; runtime cost only.	Reported exact scope above.
src/cli/kapi-review-cli.ts executable-bit churn recurred during verification.	git status showed unstaged mode-only change before cleanup.	Could add unrelated mode churn.	Reset mode before final PR state; no mode-only churn committed.
First independent review found stale autoresearch.sh service imports.	Reviewer flagged ./src/application/kapi-service.ts imports.	Runtime probes would have failed after the file rename.	Updated both probe imports plus the corpus filter and re-ran verification/review.

Risks / Follow-up

• Exported names such as KapiService, createLocalKapiService, KapiStore, KapiRegistryEntry, and KapiAgentPrReviewState remain for later Remove remaining kapi identifiers from internal codebase #209 slices.
• src/cli/kapi-review-cli.ts remains intentional for the literal external kapi-review / kapi-agent integration.
• Serialized workflow IDs and slash-command literals such as kapi-ralph, kapi-autoresearch, and /kapi-* remain compatibility contracts.

kapi-agent review

• Expected reviewer-only bot behavior: automatic formal review after PR open; if absent after a short wait, request with @kapi-agent review.
• Merge gate: latest kapi-agent approval/check must apply to the current head before merge.
• Re-review rule: after stale approval, REQUEST_CHANGES, or COMMENT, request re-review with a same-comment current-head revision explanation.

[devkade]

@kapi-agent review

Revision explanation for current head 187b58dfb555b4356eb7f154d679cedc3eab81f6:

What changed:

• Renamed application service filenames from src/application/kapi-service.ts and src/adapters/kapi-service-factory.ts to semantic workflow-service paths.
• Updated source, tests, docs, and autoresearch.sh runtime probes to use the new service module paths.
• Extended the architecture filename guard and product-name audit residual scan.

Why this closes the prior feedback:

• This is a bounded partial Remove remaining kapi identifiers from internal codebase #209 slice focused only on service/factory filenames and import paths.
• Exported names such as KapiService and createLocalKapiService are intentionally left for a later compatibility/export slice.
• The diff is reviewable: 38 files, 73 insertions, 69 deletions, primarily path updates and two renames.

Verification:

• npm test -- test/architecture.test.ts test/service-store.test.ts test/deep-interview-child-rpc.test.ts test/presentation-command-behavior.test.ts — pass; package script ran the full suite, 519 tests, 508 pass, 11 skipped.
• npm run check — pass.
• npm run check:unused — pass.
• npm run quality:budgets — pass with existing non-failing code_smells=52 warning.
• git diff --check — pass.
• Independent reviewer subagent — initial stale autoresearch.sh imports finding fixed; re-review passed.

[kapi-agent]

kapi-agent review

Verdict: APPROVE

Final approval summary

Review journey

The PR’s original goal is to remove remaining product-name leakage from internal workflow service filenames while preserving exported symbols and compatibility surfaces for later slices. The semantic scope is narrow: filename/import-path cleanup for the application service and adapter factory, plus tests/docs/autoresearch probes that reference those paths. There was no prior kapi-agent review on this head, and the PR body includes a clear revision/QA explanation.

What changed

• src/application/kapi-service.ts was renamed to src/application/workflow-service.ts.
• src/adapters/kapi-service-factory.ts was renamed to src/adapters/workflow-service-factory.ts.
• Source, tests, and runtime probe imports were updated to the new paths.
• test/architecture.test.ts now guards against reintroducing the old service filenames and asserts the semantic filenames exist.
• docs/product-name-audit.md, docs/harness-module-registry.md, and autoresearch.sh were aligned with the rename.

Why this is correct

This is a path-level refactor with no intended runtime behavior change. The implementation preserves exported names such as KapiService and createLocalKapiService, reducing compatibility risk while still removing the filename-level leakage targeted by this slice. The architecture guard makes the contract durable by failing if the old filenames return.

Evidence

• Verifier gate: PASS — npm ci && npm run verify exited 0.
• Size gate: PASS — 142 changed lines, under the 200-line semantic review threshold.
• Revision-explanation status: not required, and present.
• Ilchul review harness gate: PASS — neutral/comment, no blocking findings.
• Inspected changed source/docs/test paths and confirmed no stale kapi-service import references remain outside the intentional architecture assertions.

Remaining risks and approval rationale

Remaining risk is limited to downstream consumers importing internal, non-package-exported paths directly; this repository is private and the PR intentionally keeps symbol names stable. No blocking correctness, safety, workflow-contract, or regression issues were found, and the verification evidence is sufficient for approval.

Blocking issues

None.

Warnings / risks

• Direct external imports of the old internal paths, if any exist outside this repository, would break. This appears acceptable for an internal implementation rename and is mitigated by preserving exported symbols.

Suggestions

• In a later compatibility slice, consider renaming exported symbols (KapiService, createLocalKapiService, etc.) with aliases or migration notes if they are used outside the repo.

Looks good

• The path rename is focused and avoids mixing in symbol/API renames.
• Runtime probes in autoresearch.sh were updated, avoiding stale dynamic import failures.
• The architecture test now enforces both absence of old filenames and presence of the new semantic files.
• Documentation reflects the new residual product-name audit state.

Verification notes

• Verifier gate status: PASS — npm ci && npm run verify completed successfully.
• Size gate status: PASS — 142 changed lines, below threshold.
• Revision-explanation status: not required for this first kapi-agent review; explanation found in PR body.
• PR evidence includes full test/check/unused/quality-budget verification and residual scans.

---

Engine: pi