feat: add LexAI status bar and suggestion panel
Some checks failed
CI — Test & Build / Test & Build (push) Has been cancelled
Some checks failed
CI — Test & Build / Test & Build (push) Has been cancelled
- Implemented a status bar item for LexAI with dynamic status updates (ready, processing, notReady). - Created a suggestion panel for displaying and interacting with AI-generated suggestions. - Added functionality for accepting, regenerating, and discarding suggestions within the suggestion zone. - Introduced configuration options for writing style, prompt patterns, personas, and formats. - Integrated progress indicators for long-running tasks and improved user feedback. - Established TypeScript configuration for the vscode package.
This commit is contained in:
@@ -1,38 +1,40 @@
|
||||
# Self-model — LexAI
|
||||
# Self-model
|
||||
|
||||
> What the harness believes about the operator and this project. Kept honest by `self-model-audit`. No secrets or sensitive personal data.
|
||||
> What the harness believes about the operator and the project it serves. The point is a system that models *who you are now* and *what this project actually is* — not a stale or aspirational version. Kept honest by the `self-model-audit` skill. Contains no secrets or sensitive personal data.
|
||||
|
||||
## Operator
|
||||
|
||||
- **Who I'm building for:** John Kevin Asprec — owner/maintainer of LexAI.
|
||||
- **Working style:** ships in focused phases (Phase 1 delivered 7 workitems to a deadline); values concise, direct output over verbose explanation; comfortable with the code and the toolchain.
|
||||
- **Communication preferences:** concise and direct; minimal formatting; prefers the point over the preamble.
|
||||
- **Technical depth:** high — WXT/MV3, TypeScript, React, CI/CD. Wants surgical diffs and real verification, not hand-holding.
|
||||
- **Decision authority kept:** manifest permission changes, key-handling changes, releases (version bump + `v*.*.*` tag), and anything touching the Web Store listing.
|
||||
- **Who I'm building for:** [name / role, and the context they work in]
|
||||
- **Working style:** [how they like to work — concise vs. detailed, ask-first vs. act, review depth]
|
||||
- **Communication preferences:** [tone, formatting, length — mirror project/user instructions]
|
||||
- **Technical depth / stack fluency:** [what they know deeply vs. want handled for them]
|
||||
- **Decision authority they keep vs. delegate:** [what always needs their sign-off]
|
||||
|
||||
## Project intent (the real one)
|
||||
|
||||
- **Optimizing for:** a genuinely useful, private, subscription-free writing assistant that runs on the user's own key — shipped to the Chrome Web Store.
|
||||
- **What "good" means here:** typecheck + tests + build green, real-page behavior verified, minimal diffs, invariants preserved (see LESSONS_LEARNED), key never exposed.
|
||||
- **Non-negotiable constraints:** no backend; never transmit user text or key anywhere but the chosen provider; inline styles until PostCSS is deliberately wired.
|
||||
- **What this project is actually optimizing for:** [the outcome that matters, in their words]
|
||||
- **What "done" and "good" mean here:** [their real bar, not a generic one]
|
||||
- **Constraints that are non-negotiable:** [time, cost, stack, values]
|
||||
|
||||
## Voice (if the harness writes as the operator)
|
||||
## Voice (if the harness writes as them)
|
||||
|
||||
- **Sounds like:** direct, technical, no filler.
|
||||
- **Never sounds like:** marketing fluff, over-hedged, or padded with obvious restatement.
|
||||
- **Sounds like:** [characteristic phrasing, structure, do's]
|
||||
- **Never sounds like:** [anti-patterns, words/tics to avoid]
|
||||
|
||||
## Known drift risks
|
||||
|
||||
- "API key is encrypted" — the current tweetnacl approach is obfuscation, not protection; don't let docs or UI over-claim (see attacksurface + TASKS #2).
|
||||
- Phase-1 framing may go stale as recommendations land; re-read `TASKS.md` state before assuming what's done.
|
||||
- Tailwind is present but inactive — don't infer a Tailwind workflow from its presence in devDependencies.
|
||||
Places the model is likely to go stale or wrong. The audit checks these first.
|
||||
|
||||
- [belief that was true early but may have changed]
|
||||
- [aspirational goal the system optimizes for that recent behavior contradicts]
|
||||
- [preference stated once and never re-confirmed]
|
||||
|
||||
## Change log
|
||||
|
||||
| Date | What changed in this model | Evidence |
|
||||
| --- | --- | --- |
|
||||
| 2026-07-15 | Initial capture from README, CLAUDE.md, PHASE1_SUMMARY, RECOMMENDATIONS | repo docs |
|
||||
| [date] | [initial capture] | [source] |
|
||||
|
||||
---
|
||||
|
||||
*Update via `self-model-audit` when behavior and this file diverge. Never store credentials, financial/health data, or anything not agreed to persist.*
|
||||
*Update via `self-model-audit` when behavior and this file diverge. Never store credentials, financial data, health data, or anything the operator hasn't agreed to persist.*
|
||||
|
||||
Reference in New Issue
Block a user