Add Inwise OSS meeting-memory adapter

[Shravani889]

Inwise OSS meeting layer for QM

We are providing Inwise OSS as a local meeting-memory layer for QM. It lets a personal QM agent search meetings, transcripts, people, upcoming meetings, and action items without requiring Inwise Cloud.

This PR includes the adapter under integrations/inwise:

• a read-only inwise CLI and QM tool.json
• a QM meeting-memory SKILL.md
• an outbound laptop connector and encrypted self-hosted relay
• a reproducible QM deployment fixture and passing bridge test

Meeting data remains in the user's local Inwise installation. Inwise provides conversational memory and action-ready context management.

[time-attack]

I reproduced two blocking relay failures against head 785c8e3:

1. Unauthenticated pairing creation grows durable state without bound. After creating 300 pairings with a 1 ms TTL and allowing them to expire, all 300 records remained in the state file. One additional unauthenticated POST /v1/pairings increased the count to 301 and rewrote the file from 97,429 to 97,750 bytes. Because expired records are never removed and every creation serializes the full collection, the public endpoint permits unbounded disk growth and increasingly expensive event-loop work. Please add durable expiry cleanup plus bounded admission/rate limiting.

2. Accepted in-flight requests are lost on relay restart. I dispatched a CLI request and confirmed the edge received it with HTTP 200. After restarting the relay from the same persisted state, the edge response returned HTTP 404 (Request is no longer pending) and the original CLI request lost its connection. The pairing credentials survive, but the broker queue and response state do not because they live only in process-local Maps. This violates the repository durability requirement for queued/in-flight work and prevents safe restarts or blue-green/multi-instance operation. Please move request lifecycle state to a durable shared broker/store.

The focused package build and all three integration tests pass, but they do not cover either failure mode.

[Shravani889]

Hi, I made the changes needed. Please review and approve the PR, if everything looks good. Really excited!

…

On Wed, Aug 12, 2026 at 4:45 PM Sina Matian ***@***.***> wrote: ***@***.**** requested changes on this pull request. I reproduced two blocking relay failures against head 785c8e3: 1. *Unauthenticated pairing creation grows durable state without bound.* After creating 300 pairings with a 1 ms TTL and allowing them to expire, all 300 records remained in the state file. One additional unauthenticated POST /v1/pairings increased the count to 301 and rewrote the file from 97,429 to 97,750 bytes. Because expired records are never removed and every creation serializes the full collection, the public endpoint permits unbounded disk growth and increasingly expensive event-loop work. Please add durable expiry cleanup plus bounded admission/rate limiting. 2. *Accepted in-flight requests are lost on relay restart.* I dispatched a CLI request and confirmed the edge received it with HTTP 200. After restarting the relay from the same persisted state, the edge response returned HTTP 404 (Request is no longer pending) and the original CLI request lost its connection. The pairing credentials survive, but the broker queue and response state do not because they live only in process-local Maps. This violates the repository durability requirement for queued/in-flight work and prevents safe restarts or blue-green/multi-instance operation. Please move request lifecycle state to a durable shared broker/store. The focused package build and all three integration tests pass, but they do not cover either failure mode. — Reply to this email directly, view it on GitHub <#347?email_source=notifications&email_token=BAOK6T7E23ULYQJCSNTXG2L5JT6Q5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOJSGIYDQNZWGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4922087650>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAOK6TYRQURE3BM6W2LUNCD5JT6Q5AVCNFSNUABGKJSXA33TNF2G64TZHMYTGMJWGUZDOMZRHA5US43TOVSTWNJRGI2TMNZRHE2TPILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BAOK6T5INIOUDGLNICAU4TL5JT6Q5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOJSGIYDQNZWGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BAOK6T5H7NBR5ALND2ZTSV35JT6Q5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOJSGIYDQNZWGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[Shravani889]

Hi! Please let me know if there are queries. Would love to get this out the door this week! On Fri, Aug 14, 2026, 11:50 AM Shravani Vatti ***@***.***> wrote:

…

Hi, I made the changes needed. Please review and approve the PR, if everything looks good. Really excited! On Wed, Aug 12, 2026 at 4:45 PM Sina Matian ***@***.***> wrote: > ***@***.**** requested changes on this pull request. > > I reproduced two blocking relay failures against head 785c8e3: > > 1. > > *Unauthenticated pairing creation grows durable state without bound.* > After creating 300 pairings with a 1 ms TTL and allowing them to expire, > all 300 records remained in the state file. One additional unauthenticated POST > /v1/pairings increased the count to 301 and rewrote the file from > 97,429 to 97,750 bytes. Because expired records are never removed and every > creation serializes the full collection, the public endpoint permits > unbounded disk growth and increasingly expensive event-loop work. Please > add durable expiry cleanup plus bounded admission/rate limiting. > 2. > > *Accepted in-flight requests are lost on relay restart.* I dispatched > a CLI request and confirmed the edge received it with HTTP 200. After > restarting the relay from the same persisted state, the edge response > returned HTTP 404 (Request is no longer pending) and the original CLI > request lost its connection. The pairing credentials survive, but the > broker queue and response state do not because they live only in > process-local Maps. This violates the repository durability requirement for > queued/in-flight work and prevents safe restarts or > blue-green/multi-instance operation. Please move request lifecycle state to > a durable shared broker/store. > > The focused package build and all three integration tests pass, but they > do not cover either failure mode. > > — > Reply to this email directly, view it on GitHub > <#347?email_source=notifications&email_token=BAOK6T7E23ULYQJCSNTXG2L5JT6Q5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOJSGIYDQNZWGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4922087650>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BAOK6TYRQURE3BM6W2LUNCD5JT6Q5AVCNFSNUABGKJSXA33TNF2G64TZHMYTGMJWGUZDOMZRHA5US43TOVSTWNJRGI2TMNZRHE2TPILWAI> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/BAOK6T5INIOUDGLNICAU4TL5JT6Q5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOJSGIYDQNZWGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> > and Android > <https://github.com/notifications/mobile/android/BAOK6T5H7NBR5ALND2ZTSV35JT6Q5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOJSGIYDQNZWGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. > Download it today! > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[Shravani889]

Hi!
Looking forward to moving along on this. Please let me know what I can do to help

[time-attack]

Thanks for this, @Shravani889 — and sorry for the slow response.

We're closing this PR. Per CONTRIBUTING.md, since coding agents write most of the underlying code now, we'd rather receive feature ideas as a short human-written note in adrs/ — informal is great, just the idea in your own words — and bugs as a plain issue. If we're aligned we're happy to burn our own tokens on the implementation, and we'll credit you as co-author.

We don't want your idea to get lost, so we've captured it in #736 to triage on our side. Please feel free to open an adrs/ note if you feel strongly about the approach. Appreciate you engaging with the repo!

[Shravani889]

Thanks for the clarification and for preserving the idea in #736. Understood on the ADR-first contribution model; I won't resubmit the implementation. The tested branch and evidence in #347 remain available if they are useful while you triage the idea.

[Shravani889]

Hi, I was hopeful about seeing usage when this was first launched. We are nearing the one month mark now. Please let's push until we can publish. I added a note, please let me know what else is needed.

…

On Fri, Aug 28, 2026 at 2:47 PM Sina Matian ***@***.***> wrote: Closed #347 <#347>. — Reply to this email directly, view it on GitHub <#347?email_source=notifications&email_token=BAOK6T676QQ3YWEUE4DLOH35MH4YTA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMBRHA4TMMZSG42TNJTSMVQXG33OU5WWK3TUNFXW5JLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#event-30189632756>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAOK6T2PDZB6NFUIBF5RXYT5MH4YTAVCNFSNUABGKJSXA33TNF2G64TZHMYTGMJWGUZDOMZRHA5US43TOVSTWNJRGI2TMNZRHE2TPILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BAOK6TYTZYA7AEKTP6NK4535MH4YTA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMBRHA4TMMZSG42TNJTSMVQXG33OU5WWK3TUNFXW5JLFOZSW45FKMZXW65DFOJPWS33T> and Android <https://github.com/notifications/mobile/android/BAOK6T3TZBA4EQ2MWBHEU3D5MH4YTA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMBRHA4TMMZSG42TNJTSMVQXG33OU5WWK3TUNFXW5JLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>