Skip to content

docs: Bosun profile concepts and G13 input-path research - #6

Merged
RaapTechllc merged 1 commit into
mainfrom
cursor/docs-profile-concepts-389b
Sep 24, 2026
Merged

RaapTechllc merged 1 commit into
mainfrom
cursor/docs-profile-concepts-389b

Conversation

@RaapTechllc

Copy link
Copy Markdown
Owner

Docs-only capture of Kyle’s post-M1 profile brainstorm and the 2026-09-23 G13 input-path research note. No product code, no HID changes, and no edits to docs/PRD.md or docs/BOSUN-PLAN.md.

What landed

  • docs/PROFILE-CONCEPTS.md — Windows-Omarchy, Omarchy, Codex, Grokbot/agent, and master-prompt concepts. Related section points at the in-repo research note.
  • docs/research/ADR-BOSUN-g13-input-paths-2026-09-23.md — research lock on vendor 0xFF00 vs LGS-injected keystrokes vs an Omarchy key-emitter profile.
  • README.md — one sentence in the existing “See AGENTS.md…” paragraph linking the brainstorm.

Brainstorm only. M1 scope is unchanged.

Open in Web Open in Cursor 

…ot, master-prompt

Co-authored-by: RaapTechllc <RaapTechllc@users.noreply.github.com>
@RaapTechllc
RaapTechllc marked this pull request as ready for review September 24, 2026 03:44
@RaapTechllc
RaapTechllc merged commit 51df1c8 into main Sep 24, 2026
4 checks passed
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 24, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-09-24T03:48:11.301152Z 66ec6ea Draft marked ready
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 66ec6ea46c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +108 to +109
- LWN “hid Logitech G13 Driver 0.0.5” (2010): device identifies as HID but **“does not support standard HID input messages”**; a custom input device was synthesized in-driver. https://lwn.net/Articles/376851/
- Modern mainline work extending `hid-lg-g15` for G13 (LKML / lore, 2025–2026): looks for application collection `0xff000000`, connects **hidraw**, exposes synthetic “Gaming Keypad” + “Thumbstick” input devices — i.e. **kernel translation of vendor reports**, not a stock Keyboard Page hardware interface. (Kernel sources are GPL; Bosun must not copy them — PRD R6 / AC-12.)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Remove conclusions drawn from banned GPL G13 sources

These lines explicitly quote a historical G13 driver discussion and summarize implementation details from GPL kernel work, despite the repository's clean-room rule forbidding consultation of GPL G13 sources and requiring protocol facts to come only from docs/BOSUN-PLAN.md. Calling the material “corroboration” rather than an implementation source does not remove the provenance problem; delete these derived facts and support the conclusion exclusively with the in-repo measurements.

AGENTS.md reference: AGENTS.md:L14-L14

Useful? React with 👍 / 👎.


| Listening path | Can distinguish G1 vs keypad “1”? | Notes |
|----------------|-----------------------------------|--------|
| OS keyboard / Raw Input on **Keyboard/Keypad Page `0x07`** | **No** | Same Usage ID (e.g. Keypad 1 = `0x59`) whether produced by a real keypad or by LGS injection. |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Preserve device provenance in the keyboard-path analysis

When LGS exposes mapped keys through a distinct virtual HID device, Windows Raw Input retains the source in RAWINPUTHEADER.hDevice, so equal 0x59 usage values do not by themselves make the LGS stream indistinguishable from a physical keypad. The note itself proposes checking for a different device node at line 195; declaring this path definitively unusable before that measurement can discard a viable fallback while vendor-report reads remain blocked.

Useful? React with 👍 / 👎.

Comment thread docs/PROFILE-CONCEPTS.md

| G-key | Action |
|-------|--------|
| G22 (or user-chosen) | Insert / paste master project-start prompt |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep G22 reserved for stop-all

If this illustrative mapping is promoted into a profile, binding a prompt to G22 overrides the repository's documented emergency action: docs/BOSUN-PLAN.md states that G22 broadcasts stop-all, is bound in every layer, and cannot be overridden. Use a different key so the master-prompt concept does not remove the only globally reserved interrupt.

Useful? React with 👍 / 👎.

Comment thread docs/PROFILE-CONCEPTS.md

## Decisions for Kyle

1. **Which profiles ship in M2?** Candidates: Grokbot/agent (core), Omarchy and/or Windows-Omarchy (key-emitter), Codex, master-prompt. Recommend: agent profile first if AC-R1 is unblocked; at most one key-emitter profile in M2.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Schedule profiles after their prerequisite milestones

The current PRD assigns M2 exclusively to bosun-lcd; the profile schema arrives in M3, inject actions in M4, and agent adapters in M5. Consequently none of the listed profiles can ship in M2 as described, so asking Kyle to select M2 profiles creates an impossible milestone target and conflicts with the authoritative sequencing; phrase this as a later milestone or v1 decision instead.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants