8839075805
Implements Phases 1-8 of the TFTSR implementation plan. Rust backend (Tauri 2.x, src-tauri/): - Multi-provider AI: OpenAI-compatible, Anthropic, Gemini, Mistral, Ollama - PII detection engine: 11 regex patterns with overlap resolution - SQLCipher AES-256 encrypted database with 10 versioned migrations - 28 Tauri IPC commands for triage, analysis, document, and system ops - Ollama: hardware probe, model recommendations, pull/delete with events - RCA and blameless post-mortem Markdown document generators - PDF export via printpdf - Audit log: SHA-256 hash of every external data send - Integration stubs for Confluence, ServiceNow, Azure DevOps (v0.2) Frontend (React 18 + TypeScript + Vite, src/): - 9 pages: full triage workflow NewIssue→LogUpload→Triage→Resolution→RCA→Postmortem→History+Settings - 7 components: ChatWindow, TriageProgress, PiiDiffViewer, DocEditor, HardwareReport, ModelSelector, UI primitives - 3 Zustand stores: session, settings (persisted), history - Type-safe tauriCommands.ts matching Rust backend types exactly - 8 IT domain system prompts (Linux, Windows, Network, K8s, DB, Virt, HW, Obs) DevOps: - .woodpecker/test.yml: rustfmt, clippy, cargo test, tsc, vitest on every push - .woodpecker/release.yml: linux/amd64 + linux/arm64 builds, Gogs release upload Verified: - cargo check: zero errors - tsc --noEmit: zero errors - vitest run: 13/13 unit tests passing Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
52 lines
2.2 KiB
TypeScript
52 lines
2.2 KiB
TypeScript
/**
|
|
*
|
|
* Creates a new Selenium session with your current capabilities. This is useful if you
|
|
* test highly stateful application where you need to clean the browser session between
|
|
* the tests in your spec file to avoid creating hundreds of single test files with WDIO.
|
|
* Be careful though, this command affects your test time tremendously since spawning
|
|
* new Selenium sessions is very time consuming especially when using cloud services.
|
|
*
|
|
* Connection parameters such as hostname, port, protocol, etc. can be added along side
|
|
* browserName when you want to connect to a different remote service. This is useful
|
|
* in a situation, for example, where you start a test in native app and need to verify
|
|
* data in web app.
|
|
*
|
|
* If you start from remote service, you can pass in 0.0.0.0 for hostname if you want
|
|
* to switch to local drivers.
|
|
*
|
|
* <example>
|
|
:reloadSync.js
|
|
it('should reload my session with current capabilities', async () => {
|
|
console.log(browser.sessionId) // outputs: e042b3f3cd5a479da4e171825e96e655
|
|
await browser.reloadSession()
|
|
console.log(browser.sessionId) // outputs: 9a0d9bf9d4864160aa982c50cf18a573
|
|
})
|
|
|
|
it('should reload my session with new capabilities', async () => {
|
|
console.log(browser.capabilities.browserName) // outputs: chrome
|
|
await browser.reloadSession({
|
|
browserName: 'firefox'
|
|
})
|
|
console.log(browser.capabilities.browserName) // outputs: firefox
|
|
})
|
|
|
|
it('should reload my session with new remote', async () => {
|
|
console.log(browser.capabilities.browserName) // outputs: chrome
|
|
await browser.reloadSession({
|
|
protocol: 'https',
|
|
host: '0.0.0.1',
|
|
port: 4444,
|
|
path: '/wd/hub',
|
|
browserName: 'firefox'
|
|
})
|
|
console.log(browser.capabilities.browserName) // outputs: firefox
|
|
})
|
|
* </example>
|
|
*
|
|
* @alias browser.reloadSession
|
|
* @param {WebdriverIO.Capabilities=} newCapabilities new capabilities to create a session with
|
|
* @type utility
|
|
*
|
|
*/
|
|
export declare function reloadSession(this: WebdriverIO.Browser, newCapabilities?: WebdriverIO.Capabilities): Promise<string>;
|
|
//# sourceMappingURL=reloadSession.d.ts.map
|