@ai-digital-factory/lmt-cli 0.1.2 → 0.1.4

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.
Files changed (3) hide show
  1. package/README.md +68 -5
  2. package/dist/index.js +872 -135
  3. package/package.json +1 -1
package/README.md CHANGED
@@ -20,6 +20,16 @@ npm list --global @ai-digital-factory/lmt-cli --depth=0
20
20
 
21
21
  The package includes the non-secret Origins, Gate scopes, and SMS endpoint. Choose `--env dev` for the deployed dev service, or `--env local` for a running local stack. Only `local` and `dev` are supported; `prod` is rejected. Installing the CLI does not start services or provision credentials.
22
22
 
23
+ ## Candle Export for Runner
24
+
25
+ With a saved Operator Session, request one instrument and optional IST date:
26
+
27
+ ```sh
28
+ lmt candle-export NSE:IDEA --date 2026-10-23 --env dev --profile runner --timeout 2m
29
+ ```
30
+
31
+ Omitting `--date` asks Broker for the exchange's latest completed trading session, accounting for holidays and Finalization Grace. The stdout JSON `candleExport` contains the immutable Hosted URL, filename, resolved identity/date, source availability, reference-fetch metadata, and comparison counts. Missing data or Zerodha authentication is explained in the workbook. Export does not start Zerodha login or token recovery. Local/dev only; see `lmt --help` for exit conventions.
32
+
23
33
  ## Quick start: interactive dev login
24
34
 
25
35
  1. Obtain your Operator Login username and password. For headless login and Operator Session validation, also obtain an SMS read credential authorized to read `live-market-terminal-operator-directory` in the selected Gate scope from your administrator.
@@ -37,7 +47,7 @@ The package includes the non-secret Origins, Gate scopes, and SMS endpoint. Choo
37
47
  ```
38
48
 
39
49
  Enter your Operator Login username and password when prompted. This interactive login uses the credentials you enter; it does not require reading them from SMS. A valid saved session resumes automatically.
40
- 4. Use the menu to **Login with Zerodha**, **Check Operator Session**, **Validate Operator Session**, or **Logout Operator Session**. Zerodha login prompts for the current six-digit OTP. Validation requires the provisioned SMS credential.
50
+ 4. Use the menu to **Login with Zerodha**, **Check Operator Session**, **Validate Operator Session**, **Validate Zerodha Session**, **Resume Zerodha Validation**, or **Logout Operator Session**. Zerodha login prompts for the current six-digit OTP. Validation requires the provisioned SMS credential.
41
51
 
42
52
  Press Enter to submit each prompt. At the Operator password prompt, Escape returns to the username; Ctrl+U clears either field. Passwords remain masked. Press Ctrl+C to exit the terminal; use the logout command or menu action when you want to revoke the Operator Session.
43
53
 
@@ -85,10 +95,15 @@ First establish the Operator Session with `login`. Zerodha credentials stay on B
85
95
  2. Copy that attempt ID and submit the current six-digit OTP:
86
96
 
87
97
  ```sh
88
- lmt zerodha otp --env dev --profile my-dev-session --attempt ATTEMPT_ID --otp CURRENT_OTP
98
+ # Bash: mask entry, disable tracing, and send through the builtin printf pipe.
99
+ set +x
100
+ IFS= read -r -s -p 'Kite OTP: ' otp_value
101
+ printf '\n' >&2
102
+ printf '%s\n' "$otp_value" | lmt zerodha otp --env dev --profile my-dev-session --attempt ATTEMPT_ID --otp-stdin
103
+ unset otp_value
89
104
  ```
90
105
 
91
- Replace `ATTEMPT_ID` with `zerodha.attemptId` from step 1 and `CURRENT_OTP` with the code obtained after the challenge. Use the same environment and profile in both steps. Success requires verification of the resulting Zerodha Session through Gate. OTPs are excluded from JSON results and diagnostics and never stored.
106
+ Replace `ATTEMPT_ID` with `zerodha.attemptId` from step 1 and enter the code obtained after the challenge at the masked prompt. Use the same environment and profile in both steps. Success requires verification of the resulting Zerodha Session through Gate. OTPs are excluded from JSON results and diagnostics and never stored.
92
107
 
93
108
  From the monorepo root, use `pnpm -s cli:headless` in place of `lmt`. Both `local` and `dev` are supported.
94
109
 
@@ -99,7 +114,7 @@ lmt zerodha observe --env dev --profile my-dev-session --attempt ATTEMPT_ID
99
114
  lmt zerodha status --env dev --profile my-dev-session
100
115
  ```
101
116
 
102
- `--attempt ID` is required for `zerodha otp` and `zerodha observe`. The CLI does not remember attempt IDs. Existing saved attempt IDs are ignored and removed on the next profile-store write; saved cookies and the SMS credential remain usable. `zerodha login --otp` is rejected before network access; there is no single-pass login or automatic resume. `--otp-stdin` remains unsupported.
117
+ `--attempt ID` is required for `zerodha otp` and `zerodha observe`. The CLI does not remember attempt IDs. Existing saved attempt IDs are ignored and removed on the next profile-store write; saved cookies and the SMS credential remain usable. Argument-based `--otp CODE` and `--otp=CODE` are rejected before credential or network access. Migrate scripts to explicitly selected `--otp-stdin`; provide one six-digit line through a protected pipe and close it. Terminal input, extra lines, more than eight bytes, and unfinished input past `--timeout` are rejected. There is no single-pass login or automatic resume. See [protected OTP migration and local/dev smoke steps](docs/protected-otp.md).
103
118
 
104
119
  An expired, canceled, replaced, or failed attempt fails without starting a new login or submitting the OTP to another attempt. Explicitly run `zerodha login` again, obtain the new challenge's OTP, and submit it using the new attempt ID. A rejected OTP that leaves the attempt active returns `awaiting_otp` with Broker's rejection message and retry count; retry `zerodha otp` with a fresh code and the same ID. Every command remains noninteractive and honors `--timeout`.
105
120
 
@@ -127,7 +142,7 @@ Headless commands write one versioned JSON object per line to stdout; diagnostic
127
142
  | `1` | Action failure | Read the diagnostic; check SMS permissions or service reachability. |
128
143
  | `2` | Invalid invocation or target | Check `lmt --help`; supply `local` or `dev` and a valid profile. |
129
144
  | `3` | Operator Login required | Run `login` or interactive login with the same environment and profile. |
130
- | `4` | Validation blocked or Zerodha awaiting OTP | Read `reason`; for `awaiting_otp`, obtain the Kite OTP and run `zerodha otp --attempt ID --otp CODE`. |
145
+ | `4` | Validation blocked or Zerodha awaiting OTP | Read `reason`; for `awaiting_otp`, obtain the Kite OTP and run `zerodha otp --attempt ID --otp-stdin`. |
131
146
 
132
147
  Actions default to 30 seconds; validation defaults to 2 minutes. Headless actions and validation accept a finite deadline between 1 millisecond and 10 minutes:
133
148
 
@@ -184,3 +199,51 @@ To reproduce the packaging checks from the repository root:
184
199
  tarball=$(bash .github/scripts/pack-lmt-cli.sh /tmp/lmt-cli-package)
185
200
  node .github/scripts/test-lmt-cli-package.mjs "$tarball"
186
201
  ```
202
+
203
+ ### Zerodha validation
204
+
205
+ `lmt validate zerodha-session --env local --profile NAME` starts a new Broker-owned attempt and returns an attributed blocked report when a human OTP is needed. Resume with the same profile and explicit `--attempt ID`; add `--otp-stdin` to submit the protected human code. Without that flag, the supplied attempt is only observed. A pass requires authoritative attempt state followed by a hard session check; status alone does not pass the scenario. The resulting session stays available on the caller profile.
206
+
207
+ Interactive **Validate Zerodha Session** runs the same scenario with masked OTP input and a visible report. **Resume Zerodha Validation** asks for an explicit attempt ID. Fresh validation can replace the Operator's active Broker attempt and successful login can refresh its shared token. CLI profile isolation does not isolate that shared state. See [local/dev validation smoke steps and recorded prerequisites](ZERODHA-SMOKE.md).
208
+
209
+ ## Settings and token commands for Runner
210
+
211
+ Read ordinary Settings and their durable Settings Version with:
212
+
213
+ ```sh
214
+ lmt settings read --env dev --profile runner
215
+ ```
216
+
217
+ Save one intent by piping a single JSON object to protected stdin. Supply the version
218
+ you reviewed and only the settings you intend to change. For example:
219
+
220
+ ```sh
221
+ printf '%s\n' '{"expectedSettingsVersion":7,"entryCategories":[]}' |
222
+ lmt settings save --stdin --env dev --profile runner
223
+ ```
224
+
225
+ An empty list disables all Entry Categories; omitted fields keep their saved values.
226
+ Replacing credentials requires all four fields (userId, password, apiKey, apiSecret)
227
+ inside a credentials object supplied through protected stdin. Keep secrets in an
228
+ owner-readable input file or a protected pipe, never in command arguments or shell history.
229
+ One changed save advances one Settings Version; a current unchanged save returns
230
+ unchanged without a write. Every ordinary API write, including standalone credential
231
+ saves, requires expectedSettingsVersion. Stale saves return settings_conflict; read
232
+ Settings again and review the intended changes before submitting. A transport timeout
233
+ after submission or an unconfirmed Broker save returns uncertain with exit code 1.
234
+ Commands never retry a save. An ambiguous SMS write blocks authoritative Settings
235
+ reads and further Operator-record writes until Broker restarts and reloads its durable
236
+ record. The existing Market Watch resize recovery limitation still applies across stores.
237
+
238
+ Access-token operations use a separate version and endpoint:
239
+
240
+ ```sh
241
+ lmt token read --env dev --profile runner
242
+ lmt token replace --stdin --env dev --profile runner < /path/to/protected-token-request.json
243
+ ```
244
+
245
+ The token request contains accessToken, expected (the metadata returned by token read),
246
+ and optionally continueReplacement: true after reviewing an active-trading confirmation.
247
+ A same-token submission verifies the submitter without reinstalling the token. Ordinary
248
+ Settings Save never replaces access tokens. Token values and saved credentials do not
249
+ appear in command results.