I bring more than ten years of mobile engineering experience, including creating Sismos México, Sofie, and SOSMex. I use that experience to frame the product boundary, challenge platform assumptions, and recognize where evidence is still missing. It explains why I am investigating this problem; it does not prove that Ready Together works.
I use agents to support that work: they research the repository, draft alternatives, implement bounded changes, run tests, and surface contradictions. They do not independently define product truth, accept architectural decisions, or replace human review. Ready Together therefore treats the repository—not a human or agent chat transcript—as shared memory.
That does not mean adding paperwork to every change. A small copy correction can move from a focused task to implementation and verification. But realtime coordination, private invitations, authentication, persistence, billing, or safety-sensitive states need a trail that another contributor can inspect without reconstructing the original conversation.
One question per artifact
The workflow is easier to understand when each artifact has one job. They are not different names for the same document, and not every task requires all of them.
What bounded work is assigned now?
Outcome, scope, exclusions, acceptance criteria, owner dependencies, and validation.
What behavior must exist?
User scenarios, requirements, failure states, non-goals, and measurable outcomes.
How should a risky change work?
Threats, implementation boundaries, alternatives, rollout, and unresolved questions.
Why keep this durable direction?
The selected choice, rejected alternatives, consequences, risks, and future constraints.
What actually changed?
Exact files, review history, verification results, residual risk, and merge evidence.
What must happen next?
Outcome, scope, artifacts, decisions, validation, residual risk, and one concrete action.
The important phrase is when needed. Our contribution guide defines a direct flow for low-risk work, a lean feature flow for ordinary product behavior, and a full safety or contract flow for work such as realtime state, privacy, invitations, billing, and compatibility.
A real case: one private invitation link
The invitation handoff is a useful example because the visible request sounded simple: let someone share one normal HTTPS link through WhatsApp or another messaging app, then open Ready Together on Android or iPhone.
Issue #122 made the boundary explicit. Share and QR should carry the same link. The temporary invitation capability must stay out of the HTTP request. Opening a link must not silently create membership. No deferred-link SDK, analytics system, server-contract change, or invented signing identity was allowed into the slice.
The spec turned privacy into observable behavior
Spec 028 converted those boundaries into testable behavior for the app and the web handoff:
- Share and QR produce one byte-identical canonical HTTPS value.
- The invitation identifier and capability live after the URL fragment marker, never in the path or query sent to the host.
- The landing keeps accepted data only in memory and offers an app handoff only after a deliberate action.
- Missing, duplicate, malformed, oversized, foreign, or unsupported input fails closed.
- Android and iPhone use the same deterministic parsing rules while keeping thin native link adapters.
- The server remains the only authority for expiry, revocation, reuse, authorization, and membership.
This is the difference between saying “make the link secure” and defining what a test can actually observe.
The RFC made rejected shortcuts visible
RFC 0005 asked how to deliver that behavior without adding a second invitation authority. It compared several tempting options: keep only the custom scheme, put private data in the HTTPS path or query, validate the invitation through the website, add a deferred-link provider, or create a new server lookup contract.
The selected design keeps the public request generic and places the temporary capability in the client-side fragment:
https://ready-together.app/join#v=1&id=…&token=…Keeping the rejected alternatives in the RFC matters. A future contributor can see that server-side validation was considered and rejected because it would move a bearer capability into network traffic and create another privacy surface—not because nobody thought of it.
The ADR preserves the why—and one unfinished decision
ADR 0013 records the fragment-bound direction, its consequences, and the conditions under which domain association can be added. It also records costs: the web cannot promise invitation status, the fragment remains readable by same-page code, and physical signed-app routing still needs its own validation.
There is an important governance detail in the evidence. At the pinned source commit, both RFC 0005 and ADR 0013 are still marked Proposed. The implementation was merged under a narrower owner authorization, but merge does not silently promote a proposal into an accepted architectural decision. That status mismatch remains visible instead of being fixed by inference for this article.
Review changed the implementation
Traceability is useful only when it changes the work. The merged history contains several concrete corrections:
- The delivery grammar was reconciled with an existing admission bound.An implementation review found that decoded invitation fields also had to fit the existing 512-character admission capability. The spec, RFC, contract notes, code, and tests were updated together in commit
6fee3c2. - The website stopped diagnosing a state it could not know.The copy was revised so a generic landing would not claim an invitation had expired when only the authenticated app and server could determine that outcome.
- The one-shot handoff retained keyboard focus.Review also produced tests and corrections for focus continuity and visible focus contrast after the app-open action replaced itself.
Merged is not the same as released
ReadyTogether PR #123 merged the shared codec, Android and iOS adapters, Spec 028, RFC 0005, and ADR 0013. Its recorded validation includes JVM and Android host tests, an Android debug build, iOS shared compilation, an unsigned iOS host build, and 142 screenshot checks.
ReadyTogether-Web PR #2 merged the generic bilingual handoff with 34 web tests, lint, and a production build. The public /join route returned HTTP 200 when checked on August 29, 2026.
At that checkpoint, those facts did not prove signed physical Android App Links, iOS Universal Links, WhatsApp behavior on real devices, a complete Android-to-iPhone admission, or store release. Issue #122 has since closed and Android is now available on Google Play; the iPhone and full physical cross-platform gates remain separate from that earlier merge.
Human in the loop is part of the workflow
Every Ready Together handoff ends with the same seven fields: outcome, scope, artifacts, validation, decisions, residual risk, and one next action. This is deliberately boring. It lets me—or a future human or agent collaborator—resume from repository evidence without trusting a summary of the previous chat.
I supply the product and mobile-platform context, review the tradeoffs, and decide whether the evidence is sufficient to proceed. Agents can research, implement, test, challenge their own assumptions, and prepare a pull request. Human decisions remain explicit: accepting an ADR, merging, changing production, releasing an app, or publishing an article are different actions. The goal is not autonomous code generation. It is faster collaboration without surrendering judgment or accountability.