Add Something Real: A Second Person

You call Aster Repairs to arrange a visit. The person who answers says somebody from your office called five minutes ago. They have already agreed a time. You apologise, hang up, and try to find out who made the call.

Having help was supposed to mean less work.

Visit Book began as an app for one person. Now imagine a colleague will help with the calls from another Windows computer, in another home. They need the same business details and the latest conversations. You need to avoid calling the same person twice. An extra box labelled “Caller” won't solve this.

Start with the arrangement you want

Open the Visit Book project in VS Code and return to Codex. Explain the new job before asking for a technical change:

A colleague will help me make calls from another Windows computer at their home. We both need the current business records, notes, callbacks, and agreed visits. We must be able to tell when the other person is handling a business before we dial. Keep the native app and the records we already have. Recommend how we should share the information, including any accounts or ongoing costs. Describe what happens if one of us loses the connection while working.

A source-code copy from GitHub gets your colleague the project; an installed copy gets them the application. Neither, by itself, supplies your latest appointments.

For this example, I would use a shared online service that both apps can reach, with access limited to the two callers. Here, a service means software running on a computer your app contacts over the internet. It can keep the common records and settle requests from both callers. You still launch and use a Windows app.

Ask Codex to recommend a suitable provider and explain what you will pay, who owns the account, and how you can get your records out. Have it check current terms. You handle creating an account or signing in where required; the engineer handles connecting the app, saving shared records, and restricting access. Before real work records go anywhere new, check that you are allowed to store them there. Keep using invented businesses while you build.

If your actual situation is two computers in the same office and you want everything to stay there, say so. That is a different arrangement the engineer can design around. With the hosted service proposed for our two-home example, neither person has to leave their own computer running for the other to work.

Decide who is making the call before they dial

Seeing your colleague's last saved note won't tell you that they are on the phone right now. Both of you could open a business with no recent note and dial it. You need a way to mark who is handling the next call before it begins.

One workable design gives the caller a “Start call” action. The shared service records that they are handling that business, and the other person's app shows who it is. If both click at almost the same time, the service accepts one request and tells the other caller that the business is already being handled. The application must wait for that answer before saying the call is yours to make.

Ask Codex to implement and check that behaviour. Two screens independently declaring success would defeat the whole point.

After the call, you record the result and finish. The app releases the business, keeps who called and what they recorded, and makes the next action available to both people. The business doesn't disappear into a private list on one laptop.

Suppose your colleague stops for the evening and forgets to finish the call in the app. You need a visible way to see who left it open and take over after checking with them. Don't make yourself wait for an invisible timer, and don't let the app silently assume a slow call is abandoned. Tell Codex how you want the takeover to work and have it retain that change in the history.

Losing the connection changes what the app knows

Your original local app could work without the internet. With two callers, a disconnected app cannot know whether the other person has just started a call or changed an appointment. It should not present an old list as current merely because that looks nicer than a connection warning.

For this version, I would let you read the last downloaded records while disconnected, clearly marked as such, and keep any note you're writing. I would require a connection before starting a new shared call or confirming a changed appointment. That keeps the coordination rule understandable. More elaborate offline work is possible if you need it, but it has to resolve what both people did separately when they reconnect.

If the connection drops while you are already speaking to someone, finish the conversation and record the details. The app should preserve your note on your computer and make clear that your colleague cannot see it yet. If the change affects their work immediately, contact them yourself. Reconnecting should offer a clear way to finish saving, without making a duplicate call record or silently replacing an appointment your colleague changed in the meantime.

Ask Codex to walk you through that last case. If you and your colleague both changed the same appointment while seeing different information, one person's words should not simply vanish. The app can show the conflict and let you settle the real agreement. Codex can build the comparison; it can't infer which of two contradictory arrangements the people involved ultimately accepted without enough information.

Carry the existing work into the new version

Before changing where the records are stored, ask Codex to make a recoverable copy of the current data and save the current source version. Then have it explain how your existing businesses, call history, and appointments will reach the shared service.

You want one deliberate transfer, followed by both apps using the shared records. Sending the same old local collection from both computers could create duplicates or overwrite newer work. Tell the engineer to handle the transfer and show that the existing records remain connected afterwards. You should be able to open Aster Repairs and find the old conversations under the same business.

Once you agree on the plan, ask Codex to complete the build and produce the updated installer for both computers. Don't stop at a demonstration running inside the development tools. Your colleague needs something they can install, open, and sign into without becoming the project's engineer. Have Codex write those instructions in START-HERE.md and preserve the new shared-work decisions in PROJECT-BRIEF.md.

The AI should check the technical behaviour and access rules itself, then tell you about anything still unresolved. A plan for checks it hasn't done leaves that job unfinished.

Try working together

With the updated app on both computers, use invented records to try an afternoon's work in miniature. Have one person start a call and let the other see what happens when they try the same business. Save a callback, then find it from the other computer. Change an agreed appointment and look at the resulting schedule together.

Pay attention to the part only use can reveal. Can you tell at a glance who is handling the business? Does the app move your screen while you're reading because somebody else saved a note? Does finishing one call leave you hunting for the next? Tell Codex about the interruption and ask it to improve the arrangement. Shared information shouldn't mean your colleague remotely rearranges the screen under your fingers.

If you are practising alone, ask Codex to set up two test sessions so you can try both sides. You don't have to recruit another person to start learning how the system behaves. Once someone really joins you, their experience will supply things neither you nor the AI anticipated.

Close VS Code and Codex and do the work in Visit Book. The useful result is two people making calls with an accurate account of what the other has done, without spending the afternoon asking, “Have you called this one?”