A Private API Is Not Yet a Working Phone Connection
My AI team and I tested a private API route for phone access. Authentication worked on the server, but the iPhone connection is still an open test.
Today I worked with my AI team to prepare a private connection to Hermes for an iPhone app. We got the server-side route working. We have not yet proved that the app can use it.
That sounds like a small distinction, but it changes what I can honestly call finished.
What we actually tested
We configured an API key backed by Bitwarden and added an HTTPS endpoint accessible only through Tailscale. The endpoint accepted a valid key and rejected both an invalid key and a request with no key.
Those negative tests were part of the result, not an optional extra. A successful authenticated request showed that the intended route worked. The rejected requests showed that the checks we were relying on were active. Neither result establishes that every possible security issue has been covered.
We also checked the existing dashboard and recipe-service endpoints. Both still responded after the new route was added. That gave us a useful check that this addition had not simply replaced something else I was already using.
The phone still needs its own test
The remaining step is to connect from the iPhone and exercise the client path. A server accepting a request does not tell us whether the phone can reach it or whether the app is configured correctly.
So today's result is a tested server-side connection, not a finished mobile integration. The next check needs to happen from the device that will actually use it.
This is a concrete example of a distinction that comes up when I build with AI: preparing a capability and using it successfully are separate milestones. Today we reached the first one and left the second explicitly open.
Evidence note: this account follows today's work journal. The server-side checks are recorded there; an iPhone end-to-end test is not.