@haposoft/cafekit 0.16.0-rc.2 → 0.16.0-rc.4

package/src/claude/skills/specs/templates/task.md

@@ -1,99 +1,47 @@
 # Task R{{REQ_NUMBER}}-{{SEQ}}: {{TITLE}}
-
-**Requirement:** R{{REQ_NUMBER}} — {{REQUIREMENT_TITLE}}
 **Status:** pending
-**Priority:** {{PRIORITY}}
-**Estimated Effort:** {{EFFORT}}
-**Dependencies:** {{DEPENDENCIES}}
-**Spec:** specs/{{FEATURE_NAME}}/
-
-## Context
-
-- **Why**: {{Business/user reason this task exists}}
-- **Current state**: {{Relevant existing files, route, model, API, screen, or "greenfield"}}
-- **Target outcome**: {{Observable behavior after this task is done}}
-
-## Constraints
-
-- **MUST**: {{Non-negotiable requirement or technical constraint}}
-- **SHOULD**: {{Recommended approach or optimization}}
-- **MUST NOT**: {{Explicitly forbidden action or approach}}
-- **SCOPE**: Implement only the behavior mapped to R{{REQ_NUMBER}} and the approved `scope_lock`; do not add out-of-scope features or leave scoped acceptance criteria unwired.
-
-## Steps
-
-- [ ] 1. {{Actionable step with exact file/path/contract}}
-  - {{Business intent: what user/system behavior this enables}}
-  - {{Code detail: schema/API/component/function/route and validation rules}}
-  - _Requirements: {{REQ_NUMBER}}.{{X}}_
-
-- [ ] 2. {{Next actionable step}}
-  - {{Business intent}}
-  - {{Code detail, edge case, or integration contract}}
-  - _Requirements: {{REQ_NUMBER}}.{{Y}}_
-
-- [ ] 3. Verification implementation
-  - {{Unit/integration/e2e test or explicit manual verification hook}}
-  - _Requirements: {{REQ_NUMBER}}_
 
-## Requirements
+## Outcome
 
-- {{REQ_NUMBER}}.{{X}} — {{Acceptance criterion or requirement covered}}
-- {{REQ_NUMBER}}.{{Y}} — {{Acceptance criterion or requirement covered}}
+{{Concrete observable vertical outcome, named entrypoint, and resulting state delivered by this task.}}
 
-## Related Files
+## Scope
 
-| Path | Action | Description |
-|---|---|---|
-| `{{FILE_PATH_1}}` | Create / Modify / Delete | {{DESCRIPTION_1}} |
-| `{{FILE_PATH_2}}` | Create / Modify / Delete | {{DESCRIPTION_2}} |
+- **In scope:** {{Exact behavior owned by this task}}
+- **Out of scope:** {{Explicit exclusions or delegated behavior}}
 
-## Completion Criteria
+## Anchors and Ownership
 
-- [ ] {{Criteria 1 — observable output or artifact, maps to acceptance criteria R{{REQ_NUMBER}}}}
-- [ ] {{Criteria 2 — measurable behavior or negative-path outcome}}
-- [ ] {{Criteria 3 — maps directly to acceptance criteria from requirements.md and can be proven below}}
-- [ ] {{Criteria 4 — no orphaned component/service/route/command; created runtime-facing work is reachable from the declared entrypoint or explicitly deferred to a named integration task}}
+<!-- Compact core: one owned anchor is enough; proof artifact/owner exists only for a typed proof boundary (see Verification Plan). -->
+| ID | Type | Target | Role | Access | Action |
+|---|---|---|---|---|---|
+| A-R{{REQ_NUMBER}}-{{SEQ}}-01 | file | `{{exact/path/to/file}}` | owner | write | modify |
+<!-- For a typed proof boundary, add: | A-R{{REQ_NUMBER}}-{{SEQ}}-02 | file | `{{exact/path/to/test-file}}` | proof | write | create | and set Task role accordingly; otherwise omit. Every executable task must own a concrete test file/artifact anchor or share proof via that typed boundary; bare command is not ownership. -->
 
-## Evidence
+## Changes
 
-This section is both the task-level test plan and the proof checklist. Keep it short, exact, and executable.
-Select the proof by task risk; do not run every test type for every task.
+<!-- Every checkbox maps exact RN.M IDs; the set must equal Acceptance below. -->
+- [ ] {{Implement behavior at the exact owned boundary.}} _Requirements: {{REQ_NUMBER}}.{{X}}_
+- [ ] {{Handle the concrete negative or recovery path.}} _Requirements: {{REQ_NUMBER}}.{{Y}}_
 
-Verification: PENDING
+## Acceptance
 
-- Logic/data/validator task: include unit tests.
-- Stateful UI/component task: include component or integration tests.
-- Cross-module/API/state flow task: include integration tests.
-- User-facing end-to-end workflow: include E2E/UI flow verification.
-- Layout/theme/responsive task: include visual/runtime viewport checks.
-- Interactive UI task: include accessibility checks when keyboard, focus, labels, or ARIA can regress.
-- Scaffold/release task: include smoke build/test/dev-server checks.
-- Performance/security checks are required only when the requirement, risk, or touched surface calls for them.
+<!-- Declare each mapped RN.M once with a measurable output/state and negative behavior. -->
+- **R{{REQ_NUMBER}}.{{X}}:** {{Measurable observable outcome}}
+- **R{{REQ_NUMBER}}.{{Y}}:** {{Concrete negative or recovery outcome}}
 
-- [ ] Automated verification (unit/component/integration/E2E as applicable)
-  - Command(s): `{{TYPECHECK / TEST / BUILD COMMANDS OR N/A}}`
-  - Expected proof: {{What output, exit code, or report proves success}}
-- [ ] Artifact / runtime verification
-  - Inspect: `{{artifact path | route | UI state | DB object | manifest entry}}`
-  - Expect: {{Observable result that proves the task is really wired}}
-- [ ] Runtime reachability verification
-  - Entrypoint/caller: `{{App.tsx | route file | CLI command | worker registration | manifest | API consumer}}`
-  - Expect: {{Created component/service/route/worker/loader is imported, mounted, registered, or invoked from the runtime path; if deferred, name the later integration task}}
-- [ ] Contract / negative-path verification
-  - Check: {{Unauthorized path, validation error, permission omission, missing env behavior, deletion effect, etc.}}
-  - Expect: {{Concrete failure mode or contract-preserving behavior}}
+## Dependencies
 
-## Risk Assessment
+- {{DEPENDENCIES}}
 
-| Risk | Severity | Mitigation |
-|---|---|---|
-| {{RISK_1}} | High/Medium/Low | {{MITIGATION_1}} |
-| {{RISK_2}} | High/Medium/Low | {{MITIGATION_2}} |
+## Verification Plan
 
----
+<!-- Ownership invariant: a bare npm test command without a concrete file/artifact anchor is not ownership; shared proof must use a typed proof boundary. -->
+- **Verification ref:** {{V reference whose structured subject/proof owner matches this task}}
+- **Task role:** {{subject | verifier}}
+- **Command:** `{{Exact project command}}`
+- **Expected:** {{Exit, output, state, artifact, or UI result}}
+- **Negative path:** {{Contract-preserving failure check}}
+- **Reachability:** `{{Real entrypoint/caller or generated artifact}}`
 
-> **Parallel marker**: Append `(P)` to the title if this task can run concurrently with another (usually when serving different requirements).
-> **Test note**: If a test coverage sub-task can be deferred post-MVP, mark it with `- [ ]*`.
-> **Requirement mapping**: Every sub-task MUST end with `_Requirements: X.X_`. No mapping = invalid task file.
-> **Evidence rule**: No `## Evidence` section = invalid task file. Use `## Evidence` (legacy heading aliases still parse).
+<!-- The table above is the only task anchor/ownership table. Access read requires Action read. Access write requires create, modify, or delete. Targets are exact; globs and parent-directory claims are invalid. A verifier must not repeat the subject's Acceptance criterion. Specs-only never creates or updates docs and never fabricates execution proof; record doc impact as a brief recommendation only. -->

package/src/claude/skills/sync/SKILL.md

@@ -14,19 +14,28 @@ metadata:
 
 This skill safely bridges the gap between active development state and physical documentation files (`spec.json` + `task_registry` + `tasks/task-R*.md`). Instead of relying on risky raw AI edits, this skill executes precise contextual replacements.
 
-## Lane-aware synchronization
+## v2.1 authority-aware synchronization
 
-Read lane policy before mutating state:
+Read canonical policy before mutating state. Lane is a derived view:
 
 ```bash
 node .claude/scripts/workflow-policy.cjs --classify-lane --task-json '<task JSON>' --json
 ```
 
-- Direct may have no spec/state/registry; sync only concrete targeted evidence and never invents approval state.
-- Standard stores one bounded spec and one canonical feature receipt; one combined `code-auditor` review gates feature closeout.
-- Critical requires strict durable evidence and `inspector → implementer → test-runner → code-auditor` delegation by default.
-- `generated`, `agent_validated`, and `user_approved` are independent. Missing `user_approved` stays false; sync never auto-approves user-owned state.
-- Explicit lane overrides must preserve automatic classification and warning in receipt/state output, especially Critical downgrades.
+- Direct may have no spec/state/registry; sync only concrete targeted evidence
+  and never invents proof, readiness, approval, or audit state.
+- Standard stores one bounded spec; final integration creates one canonical
+  feature receipt. A combined closeout review is required only when the
+  persisted policy says an independent audit is needed.
+- Critical requires strict durable evidence and the persisted capability obligations; choose available actors or the main session according to required capability and independence, never a fixed actor sequence.
+- Authoring states are only `draft`, `validated`, or `absent`. Legacy approval
+  fields are readable but inert.
+- Preserve `classified_minimum`. Reclassification happens before persistence;
+  after persistence, the same-feature baseline is monotonic and no downgrade is
+  supported until a trusted issuer exists.
+- `spec.json` is machine authority. Task status/checkboxes, dependencies, and
+  ownership Markdown are projections. Typed `coordination.boundaries` are the
+  only topology authority.
 
 ## Supported Commands
 ### 1. Task Synchronization
@@ -52,22 +61,43 @@ Scans the `spec.json` against all physical `task-R*.md` files to detect mismatch
 
 1. **Precision Edits:** Never overwrite the entire `spec.json` string blindly. Update only the required keys, while keeping JSON valid.
 2. **Machine + Human Sync:** Every task status update MUST modify both `spec.json.task_registry[...]` and the matching markdown task file header/status section.
-3. **Markdown Integrity:** When marking a task `done`, only then turn `[ ]` into `[x]` inside `## Steps` / `## Implementation Steps` and relevant `Completion Criteria` / `Evidence` checkboxes that have actual proof. Use `## Evidence` (legacy heading aliases still parse).
-4. **Verification Receipt Rule:** `done` is illegal without a human-readable verification receipt already present in `## Evidence` (legacy heading aliases still parse) (commands executed, artifact/runtime proof, or equivalent concrete evidence). If proof is missing, keep the task `in_progress` or `blocked`.
-5. **Task Docs Hook:** Every time `hapo:sync` marks a task as `done`, it must flag that a task-level docs checkpoint is now due for that verified task.
-6. **Phase Prompt Rule:** When `hapo:sync` marks the final pending task in the whole feature as `done`, it should automatically prompt the user if they'd like to advance the phase, but only after the docs checkpoint for that last completed task has been considered.
+3. **Markdown Integrity:** Task Markdown is a plan plus `**Status:**`. Update
+   Status and `Changes` checkboxes only when their implementation is real; never
+   insert Base/Head, verdicts, command outcomes, or receipt proof into the plan.
+4. **Verification Receipt Rule:** `done` is illegal without a valid canonical
+   `receipts/<task-basename>.md`, or a readable legacy `## Evidence` receipt.
+   Prefer the separate receipt; if both exist and proof identity conflicts,
+   refuse completion. If proof is missing, keep the task `in_progress` or
+   `blocked`.
+5. **Task Docs Hook:** When `hapo:sync` marks a task as `done`, assess actual documentation impact and report `Docs impact: major|minor|none`; do not create a docs update request when impact is `none`.
+6. **Topology Rule:** Never infer dependency or parallel state from `(P)`,
+   `task_triggers`, `Related Files`, or prose; project typed boundaries instead.
 
 ### 4. Explicit Flash Finalization
 
-**Usage:** `/hapo:sync <feature_name> <task_id|task-file> sync-finalize`
+**Usage:** `/hapo:sync <feature_name> <task_id|task-file> sync-finalize` (the adapter must call `workflow-policy.cjs --sync-finalize --task-json <current-task> --verdict PASS --proof <canonical-receipt> --json`)
 
-This is the only operation allowed to turn a flash-promoted task (`Verification: PASS`, `status: in_progress`, `readyForSync: true`) into `done` and unblock dependencies. A normal `done` request cannot bypass flash promotion or stale `FLASH_UNVERIFIED` state.
+This is the only operation allowed to turn the current `FLASH_UNVERIFIED` task into `done` and unblock dependencies. The policy derives promotion from that current state and explicit proof; `readyForSync`, `flashTransition`, and `promotionReceipt` supplied by the caller are not proof. A normal `done` request cannot bypass flash promotion or stale `FLASH_UNVERIFIED` state.
+
+The current state must be the exact stored form: `status: "in_progress"`,
+`receipt: "FLASH_UNVERIFIED"`, `dependencyBlocked: true`, `unblocks: false`, a
+concrete blocker, and no caller promotion fields. The canonical proof must be
+bound by the runtime adapter with `policy.createReceiptBinding({ base, head })`
+and must match both receipt anchors; arbitrary valid-length Base/Head values do
+not authorize finalization.
 
 ### Flash implementation state
 
-Executable policy source: `.claude/scripts/workflow-policy.cjs` (source: `src/claude/scripts/workflow-policy.cjs`). Use `promoteFlashTask` only after exact task Evidence and reachability return PASS; FAIL, BLOCKED, and NO_TESTS remain blocked in progress.
+Executable policy source: `.claude/scripts/workflow-policy.cjs` (source: `src/claude/scripts/workflow-policy.cjs`). Trusted sync-finalize invokes `promoteFlashTask` only after the exact task Verification Plan and reachability return PASS; test PASS itself only supplies canonical proof and leaves the persisted task blocked in progress. FAIL, BLOCKED, and NO_TESTS remain blocked in progress.
+
+`FLASH_UNVERIFIED` is storage for implemented-but-unverified work, not a completion status. Store it as `status: "in_progress"` with `dependencyBlocked: true`, `unblocks: false`, a concrete blocker, and no promotion fields; do not unblock dependencies. `/hapo:test` may produce canonical proof, but the supported sync-finalize boundary must receive explicit `--verdict PASS` and `--proof`, require the runtime Base/Head binding, revalidate the receipt/artifact, derive the transition, and only then set `done`. FAIL, BLOCKED, NO_TESTS, marker-only proof, minimal state, and pre-promoted caller JSON remain `in_progress`.
 
-`FLASH_UNVERIFIED` is storage for implemented-but-unverified work, not a completion status. Store it as `status: "in_progress"` with blocker `awaiting /hapo:test <feature>`; do not unblock dependencies. `/hapo:test` may promote one task only after its exact Evidence and reachability PASS, replacing the receipt with proof, clearing blocker, and setting `readyForSync: true` while dependencies remain blocked. Only explicit `/hapo:sync ... sync-finalize` may set `done` and unblock. FAIL, BLOCKED, and NO_TESTS remain `in_progress`.
+After the last task is done, sync does not synthesize proof. Test/Develop must
+run final integration and create `feature-receipt.md` once. Task-bearing
+completion requires all task receipts plus the feature receipt. Taskless
+Compact/Full completion requires the feature receipt only; its absence before
+final closeout is normal. No receipt grants or infers approval, readiness, or
+audit status.
 
 ## References
 Read `references/sync-protocols.md` for exact Search/Replace regex patterns and JSON schema expectations before acting on the files.

package/src/claude/skills/sync/references/sync-protocols.md

@@ -2,23 +2,33 @@
 
 The following guidelines dictate exactly how `hapo:sync` should interact with files to prevent data corruption.
 
-**Flash implementation state:** `FLASH_UNVERIFIED` MUST remain `status: "in_progress"` with blocker `awaiting /hapo:test <feature>`. It never unblocks dependencies. A task-scoped `/hapo:test` PASS replaces receipt with real `Verification: PASS`, clears blocker, and sets `readyForSync: true` while dependency blocking remains. Only explicit `/hapo:sync ... sync-finalize` may set `done` and unblock; FAIL, BLOCKED, and NO_TESTS stay `in_progress`.
+**Flash implementation state:** `FLASH_UNVERIFIED` MUST remain the exact stored form: `status: "in_progress"`, `dependencyBlocked: true`, `unblocks: false`, a concrete blocker, and no `readyForSync`, `flashTransition`, or `promotionReceipt` fields. It never unblocks dependencies. The supported sync-finalize adapter must pass the current task, `--verdict PASS`, and canonical `--proof` to `workflow-policy.cjs`; the policy derives promotion, requires a runtime `createReceiptBinding({ base, head })` match for both receipt anchors, revalidates receipt/artifact requirements, and rejects caller-supplied promotion fields before setting `done`. FAIL, BLOCKED, NO_TESTS, marker-only proof, minimal state, and pre-promoted caller JSON stay `in_progress`.
 
-**Lane state rule:** classify Direct/Standard/Critical before sync. Direct may omit spec/state/registry for clear, reversible low-risk work; Standard uses one bounded spec and one feature receipt; Critical requires strict durable evidence. Explicit overrides must retain automatic lane, risk signals, and warning. `generated`, `agent_validated`, and `user_approved` are independent booleans; never infer or write `user_approved: true` from agent fields.
+**Policy state rule:** read the v2.1 policy input before sync. Direct/Standard/
+Critical are derived views. Preserve `classified_minimum`, risks, and explicit
+override receipt. Authoring states are only `draft`, `validated`, or `absent`;
+legacy approval fields are inert.
+
+**Authority rule:** `spec.json` is machine authority. Markdown is a projection.
+Typed `coordination.boundaries` own dependency, ownership, transition, proof,
+and parallel semantics; never infer them from `(P)`, `task_triggers`, `Related
+Files`, or prose.
 
 ## 1. Updating `spec.json`
 
-*   **JSON Modification Rule:** Do not output whole files. Instead, load the JSON structure, apply the update to `status`, `current_phase`, `blocker` (if any), `task_files`, and the relevant `task_registry` entry, then overwrite the file cleanly.
+*   **JSON Modification Rule:** Do not output whole files. Load the JSON,
+    update only lifecycle fields and the relevant registry entry, then write
+    valid JSON without changing semantic topology.
 *   **Task Registry Rule:** Resolve the incoming task reference to a single relative path in `task_registry`. Accept either:
     - compact task ID like `R0-02`
     - full filename like `task-R0-02-extension-shell.md`
     - full relative path like `tasks/task-R0-02-extension-shell.md`
 *   **Status Update:** If a task changes to `blocked`, the matching `task_registry[path].status` must become `"blocked"`, `task_registry[path].blocker` must record the reason, and `spec.json.status` / `spec.json.blocker` must reflect the top-level block if work is globally blocked.
 *   **Timestamp Rule:** Update `task_registry[path].started_at`, `completed_at`, and `last_updated_at` consistently with the new state. Also refresh `spec.json.updated_at`.
-*   **Done-State Rule:** Never set `task_registry[path].status = "done"` unless the matching markdown task file already contains a verification receipt in `## Evidence` (legacy heading aliases still parse), or the caller explicitly provides proof that can be written there first.
-*   **Receipt Integrity Rule:** A valid verification receipt must include the exact commands run, their outcomes, and artifact/runtime proof. Receipts containing `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or explicit "placeholder / simplified for MVP / production later" contract deviations are not eligible for `done`.
+*   **Done-State Rule:** Never set `task_registry[path].status = "done"` unless `receipts/<task-basename>.md` is valid, or a legacy `## Evidence` receipt is valid. Write proof to the separate receipt first; never add execution evidence to a new-format task plan.
+*   **Receipt Integrity Rule:** A valid task receipt includes task identity/path, exact commands and outcomes, expected versus observed behavior, applicable negative/reachability/artifact proof, and Base/Head binding. If separate and legacy receipts both exist with conflicting proof identity, refuse `done`. `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, placeholders, and contract substitutions are not eligible.
 *   **Contract Fidelity Rule:** If the task file notes or evidence show that a named framework/auth/runtime choice from the spec was silently replaced, sync MUST refuse `done` until the spec is amended or the implementation is corrected.
-*   **Task Docs Rule:** After a task is moved to `done`, emit a short alert that a task-level docs checkpoint is due for this verified task.
+*   **Task Docs Rule:** After a task is moved to `done`, assess actual documentation impact and report `Docs impact: major|minor|none`. Only affected docs receive a follow-up checkpoint.
 
 ## 2. Updating `tasks/task-**.md`
 
@@ -27,19 +37,18 @@ The structure of `tasks/task.md` relies heavily on exact keyword markers. Follow
 ### A. Completing a Task
 When `/hapo:sync <feature> <task-id> done`:
 1. Find: `**Status:** pending` (or `in_progress` / `blocked`).
-2. Inspect `## Evidence` (legacy heading aliases still parse) first. If it has no explicit proof lines (commands run, artifact proof, runtime proof, or blockers cleared), STOP and refuse to mark the task done.
+2. Resolve `receipts/<task-basename>.md` first, with legacy `## Evidence` as fallback. If neither has valid proof, STOP and refuse to mark the task done.
 3. Refuse completion if the receipt contains any non-passing marker such as `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or an explicit note that the implementation substituted a named contract with a placeholder/custom simplification.
 4. Replace with: `**Status:** done`.
-5. Locate block: `## Steps` or `## Implementation Steps`.
-6. Convert `- [ ]` into `- [x]` strictly within that section.
-7. Update relevant checkboxes in `## Completion Criteria` and `## Evidence` (legacy heading aliases still parse) only when the caller provides or the file already contains real proof.
-8. Surface a note such as: `Docs checkpoint due: task Rn-mm just completed`.
+5. Update only implemented checkboxes under `## Changes`; never append receipt fields to the task plan.
+6. Surface `Docs impact: major|minor|none`; if impact is not `none`, name the affected docs and the follow-up checkpoint.
 
 ### B. Blocking a Task
 When `/hapo:sync <feature> <task-id> blocked "API error"`:
 1. Find: `**Status:** <anything>`.
 2. Replace with: `**Status:** blocked`.
-3. Ensure that an entry under `## Blocker Log` exists recording the explicit reason (e.g. `API error`) and timestamp.
+3. Record the reason and timestamp in `task_registry[path].blocker`; do not add
+   a non-canonical task section.
 
 ### C. Starting / Resuming a Task
 When `/hapo:sync <feature> <task-id> in_progress`:
@@ -57,9 +66,18 @@ When `/hapo:sync audit <feature>` is activated:
 4. **Reconciliation Rules:**
    - Missing registry entry → create it
    - Missing disk file referenced in registry → remove or flag it
-   - Markdown says `done` but registry not done → registry wins only if evidence already exists; otherwise downgrade markdown or flag conflict
-   - Registry says `done` but markdown still pending → update markdown only if evidence exists
-   - Either side says `done` but `## Evidence` (legacy heading aliases still parse) has no concrete proof → downgrade to `in_progress` or flag conflict instead of preserving fake completion
+   - Markdown says `done` but registry not done → registry wins only if a canonical separate or legacy receipt exists; otherwise downgrade markdown or flag conflict
+   - Registry says `done` but markdown still pending → update markdown only if a canonical separate or legacy receipt exists
+   - Either side says `done` but neither receipt source has concrete proof → downgrade to `in_progress` or flag conflict instead of preserving fake completion
+   - Both receipt sources exist with conflicting proof identity → fail closed and require manual reconciliation
    - Either side says `done` but the receipt contains `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or explicit contract-substitution notes → downgrade to `in_progress` or flag conflict
 5. **Correction Alert:** Output a brief markdown alert detailing mismatches fixed and any unresolved conflicts requiring manual review.
-6. **Task Docs Alert:** If audit reveals tasks newly marked `done`, include whether task-level docs sync appears still due or already accounted for in the current run summary.
+6. **Task Docs Alert:** If audit reveals tasks newly marked `done`, include the actual docs impact; do not emit a generic docs-sync request when no docs are affected.
+
+## 4. Feature closeout
+
+- Before all tasks are done, missing `feature-receipt.md` is normal.
+- After all tasks are done, require final integration execution and one valid
+  `feature-receipt.md`; never derive it from task status alone.
+- A taskless Compact/Full spec uses the same final feature receipt and does not
+  require a synthetic registry entry.