docs: migrate project memory governance

This commit is contained in:
inman committed 2026-08-30 15:31:12 +08:00
1 parent 7b5d855b09
commit e7aa58a203
37 files changed
+942 -34

No files matched your search

@@ -0,0 +1,36 @@
# Project Positioning
## One-line Positioning
LianSyn Platform 将业务人员的自然语言指令解析为标准 operation,再由控制面、平台页面和 Chrome ERP 适配器完成确定性校验与受控执行。
## Primary Goal
让已登记的旅游 ERP 业务在统一契约、明确授权、可审计证据和失败关闭边界内被可靠解析与执行。
## Target Users / Consumers
- 使用运营模板提交下单、修改、安排、生命周期和导出指令的业务人员。
- 维护控制面、平台适配器、Chrome ERP 适配器、Schema、mapping 和业务 Skill 的工程人员。
- 通过 AgentBus 输入任务并接收业务回执的受控外部 Agent 渠道。
## Non-goals
- AI Agent/Skill 不查询 ERP、不生成内部引用、不直接声明业务成功。
- 未登记、未唯一定位或未真实验证的写能力不自动扩大执行范围。
- 项目文档不保存本地秘密、真实客户资料、浏览器 profile 或可重建运行输出。
## Core Constraints
- 活动业务规则以源码、Schema、mapping、业务登记和当前发布清单为准;`archive/` 只供追溯。
- 真实 ERP 访问或写入、任务 mutation、扩展重载、服务重启、部署和外部发送需要本轮明确授权。
- `.project-docs/` 是唯一活动项目记忆;任务作用域与 canonical 记忆分别遵守 Feature Gate 和 Integration Gate。
- 本地 `.env` 可存在但必须被 Git 忽略,不得读取、复制、归档或输出内容。
## Quality Bar
方案应保持确定性、失败关闭、最小权限、单一真相源、可恢复归档和与风险相称的自动化验证。
## Last Reviewed
2026-08-28
@@ -0,0 +1,28 @@
# Success Criteria
## Project Success
- 已登记业务能从手工输入或 AgentBus 输入稳定路由到统一 operation 契约。
- 写能力只在唯一对象、页面身份、ownership、写前投影、明确服务端响应和 action-specific 完成凭据成立时执行。
- 当前发布物、源码和机器可读发布清单逐文件、逐哈希一致。
- 项目记忆能在并行任务下保持任务隔离,并只通过串行 Integration Gate 更新 canonical 状态。
## Task Completion Standard
- 实际范围、约束、结果、验证、后续项和 durable 结论已记录到当前任务文件。
- 所有相关源码、契约、文档、测试和生成物保持同步;未知或未授权项明确保留为阻断或待办。
- `maintain-project-docs` 的所有权、漂移和完成门禁通过。
## Quality Checks
- `node --run check:repo`
- `node --run check`
- `node --run test:control-plane`
- `node --run test:legacy`
- `node --run build`
- 按已加载的 `maintain-project-docs` Skill 运行 `check_project_docs.py` 与当前任务的 `check_doc_drift.py`。
- 涉及 Skill、DOCX 或 Chrome 扩展时,追加各自官方校验、渲染或包/源码逐文件比对。
## Last Reviewed
2026-08-28
@@ -0,0 +1,30 @@
# Concurrent Task Gate
Complete this gate before the Planning Gate.
## Invariants
- One active task owns one worktree.
- Concurrent tasks use different branches and worktrees.
- Never stash, reset, move, delete, or adopt unknown work automatically.
- Feature tasks write only their own task record and uniquely named supporting records.
- Keep the active task record present until ownership is released.
- Treat `start`, `touch`, `complete`, and `release` as serialized registry transactions; lock timeout or malformed registry state blocks the gate.
- Feature-task write boundaries in this gate supersede legacy instructions to update shared or canonical project documents.
## Required Output
- Task ID:
- Mode: Feature | Integration
- Branch:
- Worktree:
- Base commit:
- Ownership result: Claimed | Resumed | Isolated | Blocked
- Other active local tasks:
## Block Conditions
- The worktree belongs to another active task and isolation did not succeed.
- An unowned worktree contains staged, unstaged, or untracked changes.
- No reliable committed base was selected for a new worktree.
- The runtime cannot keep later Git and file operations rooted in the isolated worktree.
@@ -0,0 +1,15 @@
# Context Checklist
Before planning, confirm:
- I know the task ID, mode, branch, worktree, base commit, and ownership result.
- I read the active task record and know its scope.
- I know what this project is and what it is not.
- I treat current-state as the last integrated snapshot rather than live concurrent state.
- I checked active decisions and the architecture overview.
- I identified task-specific docs that need deeper reading.
- I inspected other local task records through `task_context.py status --json`.
- I assessed code overlap separately from semantic or decision conflict.
- I reported missing peer records as unknown coordination state.
- I can name unknown, stale, or conflicting information.
- I know which updates remain task-scoped and which require Integration Gate.
@@ -0,0 +1,15 @@
# Integration Gate
Use this gate to promote completed task facts into canonical project memory.
## Requirements
- Run in an exclusively owned integration worktree.
- Hold the repository integration lock.
- Verify the task commits being integrated are present.
- Review source task records, task-prefixed supporting records, promotion candidates, and semantic conflicts in read-only mode.
- Write integration notes only to the integration task's own task record or `{task_id}__<slug>.md` supporting records.
- Ask before changing architecture direction, product behavior, or accepted decisions.
- Record source task or merge commits under `Integrated Through` in `current-state.md`.
Do not resolve meaningful document conflicts with `ours`, `theirs`, or union merge rules.
@@ -0,0 +1,30 @@
# Memory Index
Use this as the high-density entry point after the Concurrent Task Gate establishes task identity and worktree ownership.
## Startup Set
- Active task: `.project-docs/30-worklog/tasks/{task_id}.md`
- Project identity: `.project-docs/00-brief/project-positioning.md`
- Integrated state: `.project-docs/30-worklog/current-state.md`
- Decision list: `.project-docs/10-decisions/decision-index.md`
- System shape: `.project-docs/20-architecture/system-overview.md`
## Recall Pointers
- Evidence-heavy bugs, experiments, investigations: `.project-docs/50-evidence/evidence-index.md`
- Workflow lessons and repeated agent mistakes: `.project-docs/60-reflection/reflection-index.md`
- Pending promises, loops, timed follow-ups: `.project-docs/80-commitments/commitments.md`
- Integrated stale items: `.project-docs/90-maintenance/stale-items.md`
- Task-scoped conflicts: `.project-docs/90-maintenance/conflicts/{task_id}__<slug>.md`
## Project Authority Pointers
- Business entry and capability status: [`agent设计规范/business-adaptation-registry.md`](../../agent设计规范/business-adaptation-registry.md)
- Active lifecycle conclusions and immutable evidence links: [`agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md`](../../agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md)
- Current deliverables, versions, filenames, and hashes: [`dist/release-manifest.json`](../../dist/release-manifest.json)
- Retired Planning with Files snapshots: [`archive/project-history/2026-08-28/README.md`](../../archive/project-history/2026-08-28/README.md)
## Loading Rule
Keep this file short. Add shared pointers only during Integration Gate. Feature tasks keep their working context and promotion candidates in their own task record.
@@ -0,0 +1,66 @@
# Planning Gate
A coding agent must complete this gate after the Concurrent Task Gate and before writing an implementation plan.
## Peer Scope Check
Run `task_context.py status --json`. For each other owner, read only the peer task record at `Path(owner.worktree) / owner.task_record`. Use its `Scope`, `Intent And Constraints`, and `Promotion Candidates` sections to assess overlap.
Do not inspect or modify arbitrary uncommitted files in another task's worktree. Report a missing or unreadable peer record as unknown coordination state; do not silently treat it as no overlap. Code-path overlap alone is a warning. Block when semantic decisions conflict or unresolved overlap could change the plan.
## Required Output
```md
## Project Context Loaded
Task context:
- Task ID:
- Mode:
- Branch:
- Worktree:
- Base commit:
- Other active local tasks:
- Overlap or semantic-conflict assessment:
Read:
- {file path}
Relevant understanding:
- Project goal:
- Current integrated focus:
- Active task scope:
- Active constraints:
- Decisions affecting this task:
- Evidence, reflections, or commitments affecting this task:
- Files or modules likely involved:
- Unknowns, stale docs, or conflicts:
Gate result:
- Passed or Blocked
```
## Pass Criteria
The gate passes only when:
- task identity and worktree ownership are resolved
- the active task record exists and matches the owner task ID
- required documents were read
- task-relevant decisions were checked
- relevant evidence, reflection, and commitment indexes were checked when applicable
- other active local task scopes were assessed
- stale, unknown, or conflicting context was called out
- the plan respects project positioning and constraints
## Block Criteria
Block planning when:
- worktree ownership is unresolved
- an unowned worktree is dirty and has not been explicitly adopted by a human
- required worktree isolation failed or later operations cannot remain rooted there
- required documents are missing or a concurrency upgrade is incomplete
- current integrated state conflicts with the user request
- an existing decision appears to be violated
- semantic decisions conflict across active tasks
- the task changes project positioning or architecture without human confirmation
@@ -0,0 +1,7 @@
# Read Before Coding
Before editing code, verify that the implementation plan passed both the Concurrent Task Gate and Planning Gate. Confirm the task ID, branch, worktree, owner, and active task record still match.
If the plan is stale, ownership changed, or new peer scope affects the plan, return to `read-before-planning.md`. Keep every later file and Git operation rooted in the owned worktree.
Read the source files directly related to the target modules. Record feature progress, discovered constraints, verification, and promotion candidates in `.project-docs/30-worklog/tasks/{task_id}.md`; leave canonical project memory to Integration Gate.
@@ -0,0 +1,24 @@
# Read Before Planning
Before writing any coding plan, follow this order:
1. Run the Concurrent Task Gate.
2. Read memory-index.md.
3. Read the active task record at `.project-docs/30-worklog/tasks/{task_id}.md`.
4. Read project-positioning.md.
5. Read current-state.md as the integrated snapshot.
6. Read decision-index.md and system-overview.md.
7. Inspect other locally active task scopes.
Then read additional files when relevant:
- Architecture or refactor task: `.project-docs/20-architecture/module-map.md` and `.project-docs/20-architecture/data-flow.md`
- Product or behavior task: `.project-docs/40-domain/business-rules.md` and `.project-docs/00-brief/success-criteria.md`
- Ambiguous terms: `.project-docs/40-domain/glossary.md`
- Decision-sensitive task: referenced accepted ADRs in `.project-docs/10-decisions/`
- Evidence-heavy bug, investigation, or experiment: `.project-docs/50-evidence/evidence-index.md`
- Repeated workflow issue, skipped gate, or skill/script candidate: `.project-docs/60-reflection/reflection-index.md`
- Follow-up, loop, timed check, or restart-point task: `.project-docs/80-commitments/commitments.md`
- Suspicious integrated context: `.project-docs/90-maintenance/stale-items.md`
Treat shared files as the last integrated snapshot, not as live state from concurrent feature tasks. Do not write a plan until both the Concurrent Task Gate and Planning Gate pass.
@@ -0,0 +1,33 @@
# ADR-{number}: {decision title}
## Status
Proposed
## Date
{YYYY-MM-DD}
## Context
{context that made the decision necessary}
## Decision
{decision made}
## Rationale
{why this option was chosen}
## Consequences
- {positive or negative consequence}
## Supersedes
- {older ADR or decision, if any}
## Related
- {related doc or source file}
@@ -0,0 +1,28 @@
# Decision Index
## Active Decisions
| ID | Decision | Status | Date | Applies To | Detail |
|---|---|---|---|---|---|
| DOC-001 | `.project-docs/` is the sole active project-memory system; feature tasks own task-scoped records and Integration Gate owns canonical memory. | Active | 2026-08-28 | All repository work | [Governance](../../AGENTS.md) |
| ARCH-001 | AI parsers provide business semantics only; platform state, ERP resolution, execution evidence, and audit remain outside the business operation. | Active | 2026-08-28 | Parser and execution architecture | [System entry](../../README.md) |
| ROUTE-001 | The machine registry is the authority for 18 parser routes; the two passenger-list routes are Program-only. | Active | 2026-08-28 | Manual and AgentBus intake | [Machine registry](../../control-plane/src/business-routes.ts) |
| RELEASE-001 | Current artifacts, filenames, versions, and SHA-256 values are defined only by `dist/release-manifest.json`. | Active | 2026-08-28 | Release and delivery | [Release manifest](../../dist/release-manifest.json) |
| SAFETY-001 | Real ERP access/write, task mutation, extension reload, service restart, deployment, and external delivery require explicit task-scoped authorization. | Active | 2026-08-28 | Operations and maintenance | [Governance](../../AGENTS.md) |
## Superseded Decisions
| ID | Decision | Superseded By | Date |
|---|---|---|---|
| DOC-LEGACY-001 | Root `task_plan.md`, `findings.md`, and `progress.md` were the active project-memory system. | DOC-001 | 2026-08-28 |
## Decision Criteria
Create or update an ADR when a choice affects:
- project positioning
- architecture boundaries
- public behavior
- data model
- long-term maintenance
- user-facing workflow
@@ -0,0 +1,32 @@
# Data Flow
## Primary Flows
| Flow | Source | Destination | Notes |
|---|---|---|---|
| Business directive | Manual workbench or AgentBus | Route orchestrator | Source changes input/reply adaptation, not parser or confirmation policy |
| Parsing | Route orchestrator | AI Skill or deterministic Program parser | AI/Shadow/Auto/Program mode is frozen per task |
| Operation | Parser | Control-plane task and confirmation | Must validate against the same final contract |
| ERP execution | Confirmed task | Chrome extension and logged-in ERP page | Requires unique object, page identity, ownership, and write preflight |
| Completion evidence | ERP response/requery | Control-plane receipt and business reply | Evidence is action-specific; uncertain writes fail closed |
| Passenger workbook | Single `.xls/.xlsx` attachment | Deterministic encrypted canonical TSV | First row ignored, second row fixed header, exact leader-contact rules |
| Confirmation export | ERP source file | Archived source plus mobile delivery artifact | Visitor XLS becomes real XLSX; other types prefer PDF |
| Release | Editable source | `dist/release-manifest.json` and versioned artifacts | Manifest owns current hashes and filenames |
## State Ownership
- PostgreSQL owns durable control-plane task, session, confirmation, channel, audit, and outcome state.
- Production attachment bytes use the configured OSS provider; normalized sensitive fields remain encrypted.
- Chrome extension local state is bounded execution/reconciliation support, not canonical business history.
- `.project-docs/30-worklog/tasks/` owns task-local project memory; canonical project state is an integrated projection.
## External Interfaces
- Operator workbench at the control-plane service.
- AgentBus WebSocket channels and attachment delivery.
- Logged-in ERP browser pages under the Chrome extension host permissions.
- PostgreSQL, OSS, deployment gateway, and authenticated artifact download.
## Last Updated
2026-08-28
@@ -0,0 +1,34 @@
# Module Map
## Source Layout
| Path | Responsibility | Owner Notes |
|---|---|---|
| `agent设计规范/` | Business prompt, Skills, templates, registry, business pages, fixtures | Update business entry and Skill before downstream contracts when user fields change |
| `schemas/` | Current parse, execution, and ERP schemas | Historical schemas belong in `archive/` |
| `mappings/` | Current ERP fields, lifecycle, and extension-version mapping | Must stay synchronized with execution code |
| `control-plane/` | TypeScript control plane, migrations, parser and tests | Never hand-edit `.build/` output |
| `LianSyn-platform/` | Operator UI and external Agent parsing adapter | No task output or release packages |
| `chrome-extension/` | Current ERP extension source | Version bump and release synchronization required for code changes |
| `tools/` | Reusable builders, tests, diagnostics, and controlled write helpers | Tool outputs do not stay here |
| `infra/` | Deployment, backup, restore, and gateway configuration | No local secrets or database backups |
| `.project-docs/` | Durable task and canonical project memory | Governed by worktree ownership and Integration Gate |
| `dist/` | Current versioned delivery artifacts | Defined by `release-manifest.json` |
| `archive/` | Immutable dated history and evidence | Read-only authority boundary |
## Dependency Direction
- Business input/AgentBus → route orchestration → AI or Program parser → unified operation → control plane → Chrome extension → ERP.
- Business source documentation → Schema/mapping/implementation/tests → versioned artifacts; generated artifacts never become editable sources.
- Task-scoped `.project-docs` records propose durable changes; canonical documents consume them only through Integration Gate.
## Risky Or Sensitive Areas
- ERP write boundaries and reconciliation after uncertain responses.
- Attachment encryption, OSS network validation, and passenger workbook normalization.
- Cross-file release version and hash synchronization.
- Concurrent worktree ownership and canonical document integration.
## Last Updated
2026-08-28
@@ -0,0 +1,37 @@
# System Overview
## Current Architecture
Manual or AgentBus input is routed through task-scoped AI/Shadow/Auto/Program orchestration into one validated operation contract. The control plane owns task/session/confirmation/audit state, and the Chrome extension resolves the unique ERP object, enforces page and write gates, performs native actions, and returns action-specific evidence.
## Main Components
| Component | Responsibility | Notes |
|---|---|---|
| `agent设计规范/` | Agent Prompt, five parsing Skills, business templates, business registry, and stable fixtures | Editable source for business semantics; not runtime evidence |
| `schemas/` and `mappings/` | Parse-state, execution-state, ERP form, field, and lifecycle contracts | Current contracts only |
| `control-plane/` | Task/session persistence, parser orchestration, confirmation, audit, AgentBus, attachments, and receipts | TypeScript source; build output goes to `.build/` |
| `LianSyn-platform/` | Operator workbench and external parser adapter | Source and UI, not local task output |
| `chrome-extension/ltjt-order-assistant/` | Logged-in ERP resolution, preflight, native execution, response handling, and requery | Any code change requires synchronized versioned release updates |
| `dist/` | Versioned current deliverables and machine-readable release manifest | Not a compilation directory |
| `.project-docs/` | Task-isolated project memory and integrated canonical context | No runtime dependency |
| `archive/` | Date-scoped immutable history and evidence | Never defines current behavior |
## Important Boundaries
- AI/Program parsing and ERP resolution/execution share the final operation contract but do not share authority.
- Platform envelope fields such as task ID, session, parser decision, confirmation, transport, and audit never enter the business operation.
- Unknown, ambiguous, unverified, or post-write-uncertain states fail closed; automatic retries must not create duplicate writes.
- Canonical project memory is updated only under Integration Gate; feature tasks write only their task-scoped records.
## Related Decisions
- DOC-001
- ARCH-001
- ROUTE-001
- RELEASE-001
- SAFETY-001
## Last Updated
2026-08-28
+45
View File
@@ -0,0 +1,45 @@
# Current State
This file is the integrated default-branch snapshot. Feature tasks record progress in `30-worklog/tasks/{task_id}.md` and propose canonical changes for the Integration Gate. Feature tasks must not rewrite this file; it changes only in integration mode.
## Integrated Through
- Commit `7b5d855b093af39bf834fab4f41f41b37be1170d` as the inspected repository baseline.
- Integration task `20260828-migrate-project-docs-6f1a9c2d` for the project-documentation migration.
## Current Focus
Operate the current `0.5.157` release baseline safely, keep Program/AI routing and ERP execution boundaries synchronized, and close the remaining authorization-dependent validation gaps.
## Recently Completed
- 2026-08-28: Initialized `.project-docs/`, migrated durable project memory, and retired the root Planning with Files system into date-scoped history.
- 2026-08-28: Released Chrome extension `0.5.157`, Program parser `v1.0.6`, input contract/DOCX `0.5.123`, and five business Skills `0.5.125`.
- 2026-08-28: Added narrow shared-mother-plan whole-visitor export using `shared_plan + visitor-list + tid-only` while preserving child/independent `did+tid` behavior.
- 2026-08-28: Restarted the standard 8786 control plane under authorization and observed AgentBus 4/4 channels ready across repeated samples.
## In Progress
- No separate repository feature task is recorded at this integration snapshot.
## Next Recommended Steps
1. With explicit authorization, run a live read-only ERP verification of the shared-mother-plan `tid-only` whole-visitor export path.
2. With explicit authorization, perform ERP write verification for independent-order SGL/TWN and adult/child/leader headcount mappings.
3. Design a controlled public-DNS or host-allowlist fallback for AgentBus OSS attachments without weakening private-network SSRF blocking.
## Open Questions / Blockers
- Shared-mother-plan whole-visitor export has historical read evidence and static coverage but lacks a fresh authorized runtime ERP read verification.
- Independent-order SGL/TWN and four headcount categories lack authorized current-version ERP write evidence.
- Some AgentBus OSS attachment URLs can be rejected when local DNS resolves them to private or reserved addresses.
## Risky Areas
- Any ERP write, uncertain post-write state, automatic retry, or scope widening.
- Passenger workbook normalization, encrypted attachment persistence, leader-contact projection, and native ERP row capacity.
- Release synchronization across extension source, minimum platform version, mapping, ZIP, Skills, DOCX, and `dist/release-manifest.json`.
## Last Updated
2026-08-28
@@ -0,0 +1 @@
+9
View File
@@ -0,0 +1,9 @@
# Task History
This is integrated history. Feature tasks write only their task-scoped records; Integration Gate updates this file when a concise milestone remains useful.
| Date | Milestone | Result | Detail |
|---|---|---|---|
| 2026-08-28 | Project documentation migration | `.project-docs/` became the sole active project-memory system; legacy root planning files were preserved in date-scoped history. | [Integration task](tasks/20260828-migrate-project-docs-6f1a9c2d.md) |
| 2026-08-28 | AgentBus reconnect | Authorized control-plane restart completed; database, migration 014, and 4/4 channels were repeatedly ready. | [Archived legacy progress](../../archive/project-history/2026-08-28/legacy-planning-with-files-progress-final.md) |
| 2026-08-28 | Shared mother-plan whole-visitor export | Released strict `shared_plan + visitor-list + tid-only` routing and execution boundaries in extension `0.5.157`. | [Release gate](../../agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md) |
+35
View File
@@ -0,0 +1,35 @@
# Task: {title}
## Identity
- Task ID: {task_id}
- Mode: {mode}
- Branch: {branch}
- Worktree: {worktree}
- Base commit: {base_commit}
- Owner: {owner}
- Status: Planning
## Scope
- {scope}
## Intent And Constraints
- {intent_or_constraint}
## Outcome
- Not completed.
## Verification
- Not run.
## Follow-ups
- None recorded.
## Promotion Candidates
- None recorded.
@@ -0,0 +1,69 @@
# Task: Migrate project docs governance
## Identity
- Task ID: 20260828-migrate-project-docs-6f1a9c2d
- Mode: Integration
- Branch: main
- Worktree: /Users/inmanx/Documents/lwltAPI
- Base commit: 7b5d855b093af39bf834fab4f41f41b37be1170d
- Owner: codex
- Status: Ready for Integration
## Scope
- Initialize and adopt `.project-docs/` as the repository's durable project-memory system.
- Migrate known current state, architecture, domain boundaries, evidence pointers, commitments, and maintenance rules from the legacy root planning files and active project documentation.
- Archive and retire root `task_plan.md`, `findings.md`, and `progress.md` so the repository has one active documentation system.
- Update `AGENTS.md`, `README.md`, and repository hygiene tests to enforce the new entry and ownership workflow.
## Intent And Constraints
- Preserve all legacy content in date-scoped history before removing root files.
- Do not fabricate unknown project facts; keep unknowns and authorization-dependent validation explicit.
- Do not change business behavior, source contracts, release artifacts, ERP state, services, deployment, or external systems.
- Keep this migration exclusively owned under the integration lock; no sub-agents or concurrent task scopes are involved.
- Use the bundled `maintain-project-docs` scripts for initialization, ownership, validation, drift checking, and task completion.
## Plan
1. Scan active references and inspect governance/test files that depend on the legacy root planning files.
2. Freeze exact legacy files into `archive/project-history/2026-08-28/` and update its index.
3. Populate the canonical `.project-docs` brief, current state, decisions, architecture, domain, evidence, reflection, commitments, and maintenance records from verified local sources.
4. Update project entry documents and repository hygiene checks, then remove the legacy root files.
5. Run document checks, drift checks, the repository's five required gates, size/hash/link/diff checks, and complete the task context.
## Outcome
- Initialized the complete `.project-docs/` concurrency and canonical-memory tree with the bundled non-overwriting initializer.
- Claimed the known dirty `main` worktree in exclusive Integration mode and acquired the repository integration lock.
- Populated project positioning, success criteria, integrated state/history, decisions, architecture, domain rules, glossary, evidence, reflection, commitments, stale-state guidance, and project authority pointers from verified local sources.
- Updated `AGENTS.md`, `README.md`, and repository hygiene tests so future repository tasks use `maintain-project-docs` and the Concurrent Task Gate.
- Preserved the final legacy `task_plan.md`, `findings.md`, and `progress.md` byte-for-byte in `archive/project-history/2026-08-28/`, indexed their hashes, and removed the root copies to prevent dual project-memory systems.
- No business code, contracts, release artifacts, ERP state, service process, deployment, or external system was changed.
## Verification
- 2026-08-30 completion recheck: the user explicitly authorized finishing, committing, and releasing the known governance migration changes.
- `check_project_docs.py`: passed.
- `task_context.py doctor`: registry consistent.
- `check_doc_drift.py --task-id 20260828-migrate-project-docs-6f1a9c2d`: passed after resolving the initializer placeholder issue recorded below.
- Repository governance: 9/9 passed, including root boundaries, `.project-docs` authority, Markdown links, archive indexes, release hashes, and package/source equality.
- TypeScript check: passed.
- Control-plane tests: 127/127 passed.
- Legacy/platform/tools tests: 248/248 passed.
- Build: passed.
- Two macOS-generated `.DS_Store` files were moved out of the repository before the final verification; they contained no project source or task state.
- Final legacy archive SHA-256 and byte comparisons: all three passed.
## Gate Notes
- The first drift check correctly blocked six initializer-created `.gitkeep` files inside task-owned supporting directories because they had no task ID owner. The empty placeholders were removed; task records create their parent directory automatically, and future optional supporting directories are created only when a valid task-prefixed record is needed. No project information was deleted.
## Follow-ups
- Authorization-dependent ERP and AgentBus follow-ups were integrated into `.project-docs/80-commitments/commitments.md`; this documentation migration creates no additional operational follow-up.
## Promotion Candidates
- None. This task ran in Integration mode and applied the user-approved project-memory migration directly to canonical documentation.
+22
View File
@@ -0,0 +1,22 @@
# Business Rules
## Durable Rules
- `agent设计规范/business-adaptation-registry.md` is the cross-session business entry; each business maps user input, Skill/action, ERP flow, contracts, implementation, fixtures, and verification status.
- Manual and AgentBus tasks share the same 18 machine routes, task-scoped parser mode snapshot, and organization automation rules.
- The two passenger-list import routes are Program-only and wait for exactly one `.xls` or `.xlsx` attachment before deterministic normalization.
- Passenger overwrite requires confirmation when target ERP rows are occupied; after `full_replace + confirmed=true`, every attachment-specified sequence is written even when values are unchanged.
- A single strict `领队` row supplies leader contact; ambiguous, incomplete, duplicate, or structurally inconsistent leader data fails closed.
- Shared-mother-plan `整团游客信息` export is only `shared_plan + visitor-list + tid-only`; independent and concrete shared-child visitor lists remain `did+tid`.
- Real writes require unique resolution, exact page identity, ownership, write projection, explicit server response, and action-specific completion evidence.
- Current business capability and verification status come from active source/contracts and the lifecycle release gate, never from archive wording.
## Open Questions
- Fresh authorized runtime read verification remains for the shared-mother-plan whole-visitor export branch.
- Authorized current-version ERP write verification remains for SGL/TWN and four independent-order headcount categories.
- AgentBus OSS DNS fallback must preserve private/reserved-network SSRF blocking.
## Last Reviewed
2026-08-28
+13
View File
@@ -0,0 +1,13 @@
# Glossary
| Term | Meaning | Notes |
|---|---|---|
| operation | Unified validated business instruction exchanged between parser, control plane, and executor | Platform/task envelope metadata is excluded |
| parse state | Business-semantic operation before ERP resolution | Must not claim execution success |
| execution state | ERP-enriched operation after unique resolution and strict gates | Contains exact internal refs needed by the executor |
| shared plan / 母团 | Parent shared-tour plan | Whole-visitor export uses `tid` only |
| shared child / 子单 | Concrete customer order under a shared plan | Visitor list uses `did+tid` |
| Program-only | Route must use the deterministic parser and may not fall back to AI | Applies to both passenger-list routes |
| fresh requery | Read-only ERP verification performed after an action | Required except where an action-specific explicit-success credential is accepted |
| no ERP write | Evidence-backed result that the write boundary was not crossed | Must not be inferred from an unknown post-submit failure |
| Promotion Candidate | Task-scoped proposal for durable canonical memory | Accepted only through Integration Gate |
@@ -0,0 +1,16 @@
# Evidence Index
Use this index for searchable, traceable evidence records.
| Date | Topic | Status | Source | Detail |
|---|---|---|---|---|
| 2026-08-28 | Legacy project memory migration | Verified byte-for-byte | [Archive index](../../archive/project-history/2026-08-28/README.md) | Final root planning files were hashed, copied, and compared before retirement. |
| 2026-08-28 | Current release capability and real-validation boundary | Current integrated evidence | [Lifecycle release gate](../../agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md) | Defines active conclusions and links immutable evidence. |
| 2026-08-28 | Release artifact hashes and sources | Machine-verified | [Release manifest](../../dist/release-manifest.json) | Seven current artifacts and their source/hash metadata. |
| 2026-08-28 | AgentBus reconnect and runtime switch | Verified at observation time; time-sensitive | [Archived legacy progress](../../archive/project-history/2026-08-28/legacy-planning-with-files-progress-final.md) | Repeated 4/4-ready samples after authorized restart; live status must be rechecked when needed. |
## When To Add Evidence
Add a topic file when a task depends on logs, commits, test output, external docs, bug reproduction, experiments, or postmortem-level reasoning.
Keep task progress in `30-worklog/`; keep reusable workflow lessons in `60-reflection/`.
@@ -0,0 +1,35 @@
# Evidence Topic: {short title}
## Metadata
- Date:
- Status: Active | Resolved | Superseded | Stale
- Scope:
- Confidence: Fact | Inference | Hypothesis
- Source:
- Last verified:
- Stale trigger:
## Question
What needed evidence?
## Evidence
- Commit:
- Files:
- Commands:
- Logs:
- External source:
## Finding
What does the evidence support?
## Impact
What future planning or implementation should this affect?
## Open Items
-
@@ -0,0 +1,13 @@
# Reflection Index
Use this index for second-order workflow lessons.
| Date | Reflection | Trigger | Action | Detail |
|---|---|---|---|---|
| 2026-08-28 | Shared rolling planning files created repeated size pressure and forced semantic compression. | Root `task_plan.md` repeatedly approached or exceeded its fixed limit. | Replaced the legacy system with task-scoped records plus serialized canonical integration in `.project-docs/`. | [Migration task](../30-worklog/tasks/20260828-migrate-project-docs-6f1a9c2d.md) |
## When To Reflect
Create a reflection only when work reveals a reusable lesson: skipped gates, repeated mistakes, durable debugging patterns, ineffective plans, human corrections, or candidates for new scripts or skills.
Routine task completion belongs in `30-worklog/task-history.md`.
@@ -0,0 +1,54 @@
# Reflection: {short title}
## Trigger
What happened?
## Expected Behavior
What should the agent or workflow have done?
## Actual Behavior
What happened instead?
## Root Cause
Classify the cause:
- Missing trigger
- Weak gate
- Stale docs
- Unclear ownership
- Missing script
- Human decision not promoted
- Agent ignored context
- Other:
## Evidence
- Commit:
- Files:
- Session/thread:
- Command output:
- Docs involved:
## Lesson
What should future agents learn?
## Action
Choose one:
- Update docs
- Update gate
- Create script
- Create/update skill
- Add check/eval
- Ask human to decide
- No action
## Promotion
Should this become a rule, ADR, architecture note, task-history entry, skill change, or script?
@@ -0,0 +1,10 @@
# Skill Candidates
Track repeated workflow lessons that may deserve a reusable skill, script, or stronger gate.
| Date | Candidate | Evidence | Proposed Action | Status |
|---|---|---|---|---|
## Promotion Rule
If the same reflection pattern appears repeatedly or prevents a serious mistake, propose a skill update, new skill, script, or deterministic check.
@@ -0,0 +1,13 @@
# Commitments
Track future-facing memory: promised follow-ups, unfinished loops, timed checks, and restart points.
| Date | Commitment | Trigger / Due | Owner | Status | Next Action |
|---|---|---|---|---|---|
| 2026-08-28 | Verify shared-mother-plan `tid-only` whole-visitor export against the current runtime ERP path. | Explicit user authorization for ERP read access | Future authorized task | Pending authorization | Run read-only source and artifact checks without external delivery. |
| 2026-08-28 | Verify independent-order SGL/TWN and adult/child/leader headcount mappings with real ERP writes. | Explicit user authorization for controlled ERP writes | Future authorized task | Pending authorization | Use reversible values and action-specific requery evidence. |
| 2026-08-28 | Resolve AgentBus OSS attachment rejection caused by private/reserved local DNS answers. | User schedules the networking task | Future feature task | Pending | Design controlled public-DNS or host-allowlist fallback; keep private-network blocking. |
## Use
Record only commitments that should affect future sessions. Routine next steps can stay in `30-worklog/current-state.md`.
@@ -0,0 +1,42 @@
# Doc Update Policy
Use agent judgment and project context to decide what is durable. Do not use fixed keyword matching to decide whether information belongs in project memory.
## Feature Task Writes
Every repository-changing feature task updates `30-worklog/tasks/{task_id}.md`. Keep scope, intent, outcome, verification, follow-ups, and promotion candidates there.
When separate evidence, reflection, commitment, conflict, or decision-proposal records are useful, create uniquely named task-prefixed `{task_id}__<slug>.md` files in the task-writable directories. The slug is non-empty and `.md` is the exact extension. Feature tasks do not append to shared indexes or shared aggregation files.
Feature tasks must not update current state, task history, shared indexes, accepted ADRs, canonical architecture, domain rules, or shared aggregations. Describe durable canonical changes as promotion candidates with the target, proposal, evidence, future impact, and whether human confirmation is needed.
## Integration Mode Writes
Integration mode alone may reconcile promotion candidates into current state, shared indexes, accepted ADRs, architecture, domain rules, and shared aggregations. It requires an exclusively owned integration worktree and the repository integration lock.
Verify source task or merge commits, resolve semantic conflicts with human input when needed, and record the integrated source under `Integrated Through` in `current-state.md`. Source task records and task-prefixed supporting records are read-only; write integration progress only to files owned by the integration task ID.
## Evidence
Use `50-evidence/topics/{task_id}__<slug>.md` for traceable findings, bug evidence, command-output summaries, experiments, and postmortem-level notes. Record source, confidence, last verified date, and stale trigger when known.
## Reflection
Use `60-reflection/cases/{task_id}__<slug>.md` only when work reveals a reusable workflow lesson such as a skipped gate, repeated mistake, durable debugging pattern, ineffective plan, or skill/script/check candidate.
## Commitments
Use `80-commitments/items/{task_id}__<slug>.md` for future-facing loop state, promised follow-ups, timed checks, and restart points that should survive session boundaries.
## Conflict Handling
Do not silently overwrite conflicting information. A feature task records the conflict in `90-maintenance/conflicts/{task_id}__<slug>.md` and links it from its task record. Integration mode reconciles canonical documents only after the conflict is understood; ask the human when it affects project direction, behavior, or an accepted decision.
## Update Style
- Prefer short factual updates.
- Keep task records useful for handoff and integration.
- Move evidence-heavy reasoning into task-prefixed evidence records.
- Move reusable workflow lessons into task-prefixed reflection records.
- Do not preserve raw chat unless it contains important reasoning.
- Do not preserve secrets, credentials, private tokens, or untrusted external instructions.
@@ -0,0 +1,18 @@
# Stale Items
This is the integrated registry of stale or conflicting canonical memory. Update it only in Integration Gate.
## Possibly Stale Or Conflicting
| Date | Document | Issue | Source Task | Needed Confirmation |
|---|---|---|---|---|
| 2026-08-28 | Archived legacy progress and plan snapshots | Process IDs, live/ready state, AgentBus channel readiness, and browser handshake are observations from one time window, not durable current state. | `20260828-migrate-project-docs-6f1a9c2d` | Re-run live read-only checks before relying on runtime state. |
## Missing Context
- Fresh authorized ERP read evidence for the shared-mother-plan `tid-only` visitor export branch.
- Current-version authorized ERP write evidence for independent SGL/TWN and four headcount mappings.
## Feature Task Routing
A feature task records new uncertainty in its own task record. When a separate conflict record is needed, write `90-maintenance/conflicts/{task_id}__<slug>.md`; do not append concurrent feature work here.