What the documents look like
Franchisee training and opening coaching transfers operating capability. It differs from franchise registration disclosure, which is a legal filing activity. The working materials are training sign-in sheets, opening checklists, SOP manuals and assessment scores. They come from the training system, the supervisor app, store photographs and the headquarters SOP library. These materials refresh per store and per month.
For the deployment and upgrade step, the practical question is which version of each document is current and which version is the target. A sign-in sheet records attendance and a checklist records inspection results. Neither document grants operating permission. A retrieval hit, a form submission or a filled field does not create authorization. Approval, database writes and external synchronization require separate downstream implementation that the documents do not describe.
Constraints at the upgrades step
Materials record training and inspection outcomes. They do not carry approval status, and they do not state who may edit the SOP library. When a handover request arrives, the request text and the supporting records must be compared as separate items.
Hypothetical exercise sample. The training sign-in sheet reads: "5 March 2026, franchisee A completed the cashier and inventory course; signatory: A; confirmed by supervisor B." The opening checklist reads: "8 March 2026, store A materials inspection: cashier counter, price tags and fire exit passage pending re-check; inspector: supervisor B." The proposed handover request reads: "Transfer SOP editing permission for store A to franchisee A, effective 9 March 2026." This request carries no authorization approval record. The permission scope and the effective conditions are not stated, so the request remains a matter to be verified.
The upgrade guide for v4.17.2 lists two manually triggered migration scripts. The historical chunk training task migration converts legacy chunk training tasks into the new mode that associates formal data rows. It is manually triggered and does not block service startup. The guide states that it should be run after confirming that all old-version FastGPT App and Pro instances in the cluster have fully stopped and old task leases have expired. The dataset rebuild status migration depends on the first migration completing. It is also manually triggered and does not block service startup, and it moves legacy rebuilding markers and transitional states into the new indexStatus rebuild state system.
The v4.17.2 release notes describe a three-state data index flow: parsed, indexing and indexed. Data awaiting indexing is isolated from the retrieval layer and is not recalled, and the front end provides read-only viewing. The back end intercepts editing, deleting and index modification for such data. Training-failed data supports direct editing or deletion. These are documented behaviors of the release, not settings that this page configures.
Configuration and implementation checks
The table ties each row to the documents on this page. Starting values marked as hypothetical are exercise choices for comparison, not official defaults.
| Check item | Hypothetical starting value for this exercise | What it is compared against |
|---|---|---|
| Deployment version | Current v4.17.2 | Target version and its corresponding upgrade notes |
| AIPROXYAPIENDPOINT | Assumed http://aiproxy:3000 | Service root address; no /v1 appended |
| AIPROXYAPITOKEN | Assumed administrator token matching the server | Non-empty and consistent with the AI Proxy server configuration |
| Migration execution precondition | Assumed old App and Pro instances stopped | Old task leases expired before triggering the manual migration |
| Post-upgrade verification sample | Assumed reuse of the same training sign-in sheet | Import, retrieval and application invocation results |
| Index state check | Assumed a data row in indexing state | Documented parsed, indexing and indexed flow and its retrieval isolation |
The endpoint and token rows follow the documented requirement that both App and Admin set a non-empty AIPROXYAPIENDPOINT and AIPROXYAPITOKEN, and that missing either causes startup validation to fail. The endpoint takes the service root address without /v1. The migration precondition row follows the upgrade guide wording about stopping old instances and waiting for lease expiry. The verification sample row is a comparison method, not a claim that a test ran.
Three common errors
- Treating a retrieval hit on the training sign-in sheet as a granted permission. The input is a retrieval result; the comparison object is an authorization approval record. When the approval record is absent or names a different subject, the permission claim is unsupported. The sign-in sheet confirms course completion by franchisee A and supervisor B's confirmation, and it says nothing about SOP editing rights.
- Recording the three pending re-check items on the opening checklist as failed. The input is the checklist text; the comparison is the same field's value. Pending re-check and a failed determination are different facts. The checklist states that the cashier counter, price tags and fire exit passage are pending re-check, and it does not state a re-check conclusion.
- Treating the effective date in the proposed handover request as an already-effective permission. The input is the request text; the comparison covers signature, cooperation reached and contract effective as three separate facts. The request names 9 March 2026 as the effective date and carries no authorization clause, so the evidence gap stays open.
How to verify the setup
- Input the sample sign-in sheet and the proposed handover request. Compare subject, object, period and field. Observe whether the same subject, same period and same field carry mutually exclusive values. With no authorization record present, record the item as pending verification rather than as a denial. The sign-in sheet names franchisee A and supervisor B for 5 March 2026, and the request names franchisee A for store A from 9 March 2026; the two do not cover the same field.
- Input the sample opening checklist. Compare the three pending re-check fields against the re-check conclusion field. Observe whether a conclusion is stated. When it is not stated, keep the gap open and do not infer pass or fail. The checklist text supplies the three pending items and the inspector, and it supplies no conclusion.
- After the upgrade, reuse the same sample to review import, retrieval and application invocation. Observe whether returned results match the pre-upgrade records. For an empty result, a paper input of
[]can be used to check the downstream design; this does not establish that a fictional rule query returns empty. The v4.17.2 notes describe retrieval isolation for data in indexing state, and any observation about a specific dataset remains an observation about that dataset.