vibe64 0.1.30 → 0.1.32
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Colleague upgrade recovery
|
|
2
|
+
|
|
3
|
+
After an application upgrade, an older Colleague history may require maintenance
|
|
4
|
+
before it can open. The workspace operator performs this maintenance; Colleague
|
|
5
|
+
cannot perform it through chat.
|
|
6
|
+
|
|
7
|
+
If the application reports that its state upgrade cannot finish, retain the error
|
|
8
|
+
and ask the workspace operator to inspect the original conversation and operation
|
|
9
|
+
receipts. Do not delete the conversation, start fresh, or resend the old request
|
|
10
|
+
to bypass the upgrade error.
|
|
11
|
+
|
|
12
|
+
The operator uses the candidate release's upgrade command with the service and
|
|
13
|
+
all other writers stopped. A stale completed operation marker may require the
|
|
14
|
+
explicit receipt repair before the ordinary upgrade can finish. That repair
|
|
15
|
+
preserves the complete operation receipt and the conversation history. Native
|
|
16
|
+
continuity checks still run afterward: the completed marker alone does not prove
|
|
17
|
+
a native request completed. Unfinished or uncertain work still blocks activation.
|
|
18
|
+
|
|
19
|
+
After successful maintenance and activation, reopen Colleague through its usual
|
|
20
|
+
control. Written messages remain available, and the old request is not repeated.
|
|
21
|
+
If the error persists, provide its exact text to the operator; do not retry the
|
|
22
|
+
old action to manufacture a completion receipt.
|
|
23
|
+
|
|
24
|
+
The same recovery applies on desktop and mobile. Colleague can explain the error
|
|
25
|
+
and guide you to the available application controls, but this maintenance requires
|
|
26
|
+
the operator's interaction and cannot be executed through Colleague actions.
|
|
27
|
+
|
|
28
|
+
An older interactive chat may also use a native input format from before the
|
|
29
|
+
application recorded its autonomous flag. The operator can apply the separate
|
|
30
|
+
qualified historical correction after checking the exact original native input,
|
|
31
|
+
completed answer and account/scope custody. It preserves the chat and its native
|
|
32
|
+
identity. A missing flag by itself is not permission to resume or resend anything;
|
|
33
|
+
unsupported or uncertain native evidence still prevents activation.
|
|
@@ -199,11 +199,9 @@ Review and recording controls live beside the same typed composer. Microphone pe
|
|
|
199
199
|
and recording require your interaction; Colleague can explain the steps but cannot
|
|
200
200
|
grant permission or press them for you.
|
|
201
201
|
|
|
202
|
-
After an application upgrade, an older Colleague history may require
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
this through chat. Written history is preserved, and interrupted operations are
|
|
206
|
-
not repeated.
|
|
202
|
+
After an application upgrade, an older Colleague history may require an operator
|
|
203
|
+
state upgrade before it can open. Written history is preserved; interrupted work
|
|
204
|
+
is not repeated. See [Colleague upgrade recovery](colleague-upgrade-recovery.md).
|
|
207
205
|
|
|
208
206
|
## Ask Colleague to coordinate
|
|
209
207
|
|