Changelog

Your starred item first, Miriam, because you were right that it decides whether this place launches full or launches empty. When a collaboration locked its terms, the site quietly made the event out of what it already knew and then handed the host a preview of that half-empty thing — description, host, positions, cover photo, ticket link, the credits, all of it hiding behind an Edit button most people would never think to press. So events went live thin. As of today the full form is the front door, not the back room. A newly drafted event opens straight onto “Fill in your event,” with the date you already negotiated sitting there filled in, every detail waiting to be added, and Preview is what it should have been all along — the last look before it goes live, not the gate that unlocks the real form. One surface does the whole job now: filling in a new event, republishing a cancelled one, editing a live one. Same room, three different signs on the door.

While walking that flow the way you did, we tripped on something real: a draft the map couldn’t place stored a blank neighborhood, and the form quietly refused to save with no message at all — the button just did nothing. That is exactly the kind of silent wall your walkthrough was hunting. It’s gone; neighborhood is optional now, and blank simply means “don’t show one.” Which is also how the “TBD, Portland, Oregon” cards you screenshotted went away — we stopped writing that placeholder in the first place, and every card, calendar, and map bubble now knows to say nothing rather than say TBD.

Then the big behavior spec, and this is the one that rearranged the plumbing. Publishing and the Needs Board used to be tangled into a single switch, which is why a live event that went back to the board to find one more collaborator would vanish off the map. They are two separate facts now. So the loop runs the way you drew it: an event made inside the marketplace can’t go public while its board is open — Publish sits there disabled and says why, “Resolve or close your Needs Board to publish,” with “Remove from Needs Board” as the honest way around it. Close the board and the site walks you straight to Preview & Publish instead of leaving you to find it. Fill the last open spot and the board closes itself, so nobody is ever stuck staring at a full board wondering what to press. And once you’re live, going back to the board for another pair of hands never touches your published event — the card stays on the map the whole time. Close the board again after adding people and the site asks the one useful question: update the published event with these new changes? Say yes and the live card picks up the new lineup.

One reversal to name plainly, because it was your own earlier call: back in May you asked for a “publish anyway” option so a host could go live with positions still open, on the theory that being public is what fills them. Your new spec draws the harder line — an in-house event is born incomplete, so it earns the map by finishing or closing its board — and the new spec wins. Events added from outside skip all of this and publish directly, exactly as you said, because a venue’s own event was already a real event before it got here. The needs board itself is a true either-or now too: on it or off it, one button that always says which, and no more “posted but closed to new applicants” purgatory. If you close it early with people still waiting to be answered, they don’t evaporate — a small link keeps their applications one tap away.

The bar question you flagged was two questions wearing one coat. “Your drink plan” asked what a concept is serving and what it needs from the venue in a single row of radio buttons, so a concept pouring alcohol that also needed the whole prep-and-serve setup had to pick one and lie about the other. It is two questions now, in your words: what you’re serving — check as many as apply, with “not serving drinks” politely clearing the rest — and, only if you are serving something, what you need from the venue. Serving alcohol finally does what it should: it opens the permit question and the one about who carries coverage. On the venue side the “Non-negotiable” checkbox next to the liquor license is retired; a venue simply says whether it holds a license, and a No leads to the three follow-ups you listed — I’ll get the temp permit, the concept has to get it, or no alcohol here regardless.

The payoff is in the negotiation table, where the two answers now meet as an “alcohol coverage” line that settles itself when it can — the venue is licensed, or the venue will carry the temp permit, or the concept volunteers and the venue is expecting that, or the concept holds its own license. When both sides are willing to carry it, the line asks who actually will. And your two dealbreakers — a venue that serves no alcohol regardless, or each side quietly expecting the other to get the permit — surface as a value conflict right on the line, out in the open, never filtered away, because one side can always give. Small honesty note: the table already had a value-conflict outcome, so this is that same mechanism doing new work, not a new color.

The needs-posting form got the two mobile fixes. The Flat rate / Hourly / Tipped pills weren’t missing “Tipped” on anyone — the row just refused to wrap, so on a phone the third pill fell off the edge. It wraps now; everything is reachable. And the bare “Qty” box next to each supply category is gone, per your model: checking Photography or Floral is itself the open call, and “natural wine for forty guests” goes in the notes, which finally has room to show its own example. Cards read “Open call” or “Filled” now instead of “1 of 1.” One consequence worth naming: an old posting that once asked for three of something now reads Filled after the first — that is your new model applied honestly to old rows, not an accident.

The message thread stopped hiding. Every collaboration card shows the whole conversation right there, scrollable and open, with the compose box beneath it — no more Message button to discover, no more “hidden thread” and “opening line stranded above the details,” which were, as you spotted, one bug seen from two sides. The very first outreach — “any interest in collaborating?” — is simply the first message in that thread now, and replies work before anyone accepts, so people can negotiate before they commit. Loading them all costs one trip to the database rather than one per card, so a long page of collaborations doesn’t slow to a crawl.

And two calls made on your behalf, flagged for your eye. You asked us to confirm whether Collaborator Credits should be user-facing at all, since it was a box of raw code — we kept it visible but made it human: name and role rows you can add and remove, no braces in sight, saved the same way underneath. Say the word if it should disappear entirely instead. And the positions placeholder now shows one role per line the way its label always promised, with a small hint underneath, because some phones flatten placeholder line-breaks and we’d rather be understood twice than once.

This one answers the question you floated on July 9 and called an overreach. It wasn’t. The problem was real: a collaboration request, a changed term, a message — all of it only lived inside the site, which means it only worked if people happened to log in. A deal could sit three days waiting on someone who had no idea it existed. As of today, the time-sensitive marketplace moments also land in your inbox: collaboration requests, term changes, and direct messages send an email with a link straight back to the item. Everything else — reviews, system notices, the ambient hum — stays in-app where it belongs. The inbox is for things that stall other people, nothing more.

Everyone gets a switch in Manage My Account — "Email me about collaboration activity," on by default, off in one tap. And a decision made on your behalf, worth saying plainly: you offered a fallback of showing members’ secondary contact info to their collaborators, and we deliberately did not build it. Email alerts solve the same problem without ever exposing anyone’s personal email or phone number to another member. If someone opts out of the emails, their choice is to be slower to respond — not to have their contact details published.

Two quiet guardrails came along: the demo partners on the sandbox generate real notification traffic all day, and none of it will ever send actual mail — bounced email to fake inboxes is how a domain gets a bad reputation with the mail carriers, and we like our clean record. And every email is built defensively from the notification text, so nothing a member types can smuggle anything into someone else’s inbox.

The wiring made this almost free: every notification on the site already flowed through one door, so teaching that door to also send mail covered all twenty-five places notifications come from without touching any of them. Your instinct in that email — "members receive time sensitive information in a realistic time frame" — is now just how the site works.

Straight off your Build Gap doc, Miriam — and you were right to call it a gap, not a request. When the capability section shipped, the kitchen half landed exactly as you specced it: check Kitchen Access, get the full equipment checklist. The bar half didn’t make the boat. Bar Setup opened one lonely text box, and a sentence like "full liquor, beer/wine only" is something a person can read but the matcher can’t. That’s fixed now, with the exact structure you drew.

A venue now checks off what its bar HAS — one canonical list, grouped the way you grouped it: the base any bar service needs, the wine additions, the cocktail service station, the prep bench. Nobody asks a venue "what kind of bar program are you" — a bar is a fixed setup, not a plan. Instead the site works out what the checked boxes add up to and wears it as a badge: beer-capable, wine-capable, cocktail-capable, supports on-site prep. The badge updates live while you’re still checking boxes, which turns out to be quietly satisfying. Your free-text box survives at the bottom of the section, for the things no checklist covers.

The concept side got the mirror you asked for, voiced from its own direction — "The venue must have," select what you need the venue to provide. It starts with the question a concept can actually answer: what’s your drink plan? Serving alcohol, serving without it, prepping offsite and just need a bar to pour from, need the whole prep-and-serve setup, happy for the venue to handle drinks entirely, or not serving at all. The plan reveals only the relevant slices of the same canonical list, and anything left unchecked means "not needed, or we’re bringing it ourselves" — so an unchecked box is information too.

The payoff lands in the negotiation table: matching is now item against item, and the tier labels never have to agree across the two forms. When a concept’s needs fit inside a venue’s inventory, the row settles itself. When they don’t, the gap names names — "venue is missing: juicer, blender — confirm who provides these" — which is a conversation starter instead of a shrug.

One judgment call made on your behalf, flagged for your eye: your doc lists the six drink-plan options as one flat gate, so we read the serve-only versus prep-and-serve scoping from the gate itself — only "need prep AND service onsite" reveals the prep bench items. If a different plan should unlock a different slice, that’s a one-line change.

And your rewrite of This Is Not For Everyone is live too. The first three paragraphs were already word-for-word yours; the back half now carries the new ones — the love letter widened from owner to dishwasher, farmer to delivery driver, and the room policy stated plainly. The closing creed stands alone now, set off under a gold rule. About has no creed treatment yet to mirror, so this one sets the pattern; if it should look different, say the word. Thank you for writing specs this buildable — a doc that says exactly what remains, in build order, with the voicing rules bolded, is a gift.

You have been telling us for a while what The List should feel like — and building it, one lookbook page at a time. Today it stopped being a preview. The whole site now speaks the visual language you chose: the gritty display face on the big headlines, the typewriter voice everywhere else, true black and brand yellow as equal partners, and every card wearing the same warm off-white with a black frame and a yellow top edge. One card system, not three.

Here is the part we are quietly proud of, because it is the payoff of a month of unglamorous groundwork: the repaint itself touched four files. For weeks we had been rewiring the site so that every color, every font, every repeated shape flows from one small set of dials instead of being hand-painted in hundreds of places. When the moment came, applying your system was turning those dials. And that is not just a launch-day trick — it means every note you send from here on is a one-line change, not a renovation.

The rewiring also flushed out some very old ghosts. Hundreds of places in the code were asking for colors and corner-roundings by names that had never existed — so muted text was rendering dark, boxes that should have had soft corners were rendering square, and on the public submit form, tapping a category chip gave you no visual feedback at all, because the "selected" style pointed at a color that was not there. All repaired. Some things simply look right now that were quietly wrong for months.

A few decisions are parked and waiting for your eye, listed where you can find them: whether form fields stay crisp white or go warm, how small the gritty face is allowed to get before it muddies, and what happens to the blues and violets your system retires. Each one is a single line of code away. Walk the sandbox, send notes, and watch them land fast.

You accepted the build, and we flipped the switch: everything that has lived on the sandbox since early June is now the live site. This was the largest single release The List has ever had — the entire Master Build, in one careful move.

What the public got today, all at once: the reworked profile forms for all four member types, the negotiation table with its living agreement, crew consent and the edit cascade, the claim flow, the new schedule and daypart filters, the neighborhood map you can tap, real file uploads, duplicate detection at every door, a faster homepage, and the security hardening — the locks went on the live site the moment the release did.

The move itself was rehearsed before it was real. We took a fresh copy of the live database, practiced the entire migration against it, and confirmed the new rules fit your real data perfectly — including proof that no existing records collide with the new duplicate protections. Then the real thing ran the same script. There was one hiccup: the site build and the database change raced each other, the build lost, and for a few minutes the old site simply kept serving while we re-ran the build against the finished database. Nobody outside would have noticed anything but the before and the after.

The freeze is over. From here, changes flow to the live site the normal way — small, steady, and rehearsed — instead of gathering behind a dam. Thank you for the sign-off, Miriam; the dam held exactly as long as it needed to.

This one came straight off your addendum, Miriam, marked priority — and it earned the marking. The same real-world event lives in a lot of places at once: the venue’s Instagram, the concept’s Instagram, a friend’s repost, sometimes already on The List itself, published properly through a collaboration. Until now, nothing stopped that event from being entered a second time from one of those other vantage points, and the doubles had to be found and chased down by hand. You found three pairs on the live site during walkthroughs; that was three too many.

Now every event checks itself against the whole catalog on the way in — whether it arrives through the public submit form or through the admin scrape tool. If it is the same event in different clothes (capital letters, an ampersand, a missing apostrophe — none of that fools it), the door simply does not open: the existing listing is shown instead. If it merely looks like a likely match — the terse version of a title against the full flowery one, same night, same venue — you get a gentle "looks like this may already be on The List," with the existing event to compare against, and an "add anyway, it’s a different event" button if you know better. Choosing "add anyway" quietly tells the admins to take a look, so nothing slips through on a shrug.

The judgment calls were the real work here. Two different nights at the same venue with the same name — a weekly pasta night — sail through untouched. Trivia Night and Karaoke Night at the same bar on the same evening are strangers, and the tool knows it. And if the match is an event that came through a collaboration, the warning points people to that listing rather than letting a shadow copy of it grow.

One more thing: we ran the new detector over the live site, read-only, as a rehearsal. It found exactly the pairs you had spotted by eye — plus one more hiding at Sun Rice. The list of four is waiting on your call for which of each pair stays; say the word and the losers disappear.

Not every good week produces something new to click on. This one was spent making the machine simpler — the kind of work that pays rent forever. We went looking for anything that existed twice, anything that existed for no reason, and anything that had quietly drifted out of tune, and dealt with all of it in five careful passes.

Gone entirely: an old prototype of the homepage that was still reachable if you knew the address, and the leftover dispute machinery from a feature you retired back in April — buttons, screens, and plumbing that could never be reached again but sat there confusing every fresh read of the code.

More interesting were the twins. The demo partners on the sandbox — the ones that accept collaborations and confirm terms so you can rehearse the whole dance solo — had grown their own private copy of the steps a real person’s click performs. Two copies drift, and drift they had: deals locked by a demo partner could end up with blank terms, and — the best catch of the week — events published through a collaboration were being left invisible to the public map, marked forever as "ready" instead of "live." That one was a real bug hiding in plain sight, found only because tidying forced us to read both copies side by side. There is exactly one copy of every step now, shared by humans and demo partners alike, so that whole species of drift is extinct.

Smaller catches along the way: two partners confirming "publish" at the same instant could double-send the "Event Published!" cheer to everyone involved — now exactly one wins the race; re-negotiating a deal used to leave the draft event stale on one path; and about half the collaboration notifications were missing the little tag that lets a tap on your phone land inside the right profile — all of them carry it now.

Every one of these passes shipped with a written promise of exactly what would change and proof that nothing else did — the boring discipline that makes a tidy-up safe instead of brave.

Behind the scenes, the way changes reach The List grew up this week.

Every proposed change now gets its own complete, private rehearsal copy of the site — pages, sign-in, and its own private database, sealed off from the real ones — and a small robot walks the actual flows on it before the change is allowed in: submitting, applying, negotiating terms, publishing. Paid for itself on day one, catching a crash in the collaborations screen that every other net had missed.

Changes to the shape of the database itself — the riskiest kind — now rehearse against a throwaway copy first, and anything destructive is stopped cold unless it is explicitly, deliberately waved through. The days of a schema change reaching the live site on trust are over.

None of this is visible on any screen, which is rather the point: the visible things get to keep working.

This one is different from every batch before it. It did not start with a list of things that were broken — it started with the document you wrote, the one that lays out how the whole matchmaking pipeline is supposed to work end to end. We built it, all of it, and it is up on the sandbox for you to walk through before it goes live. Because it is a lot, this note is deliberately specific about what is actually different on each screen, so you can go check each one.

The Venue form. Kitchen questions used to be a scattered checklist; they now sit behind one "Kitchen Access" toggle that opens into equipment, prep space, cold storage, and a single gas-or-electric choice. Security and cleaning are no longer yes/no — each is "not available / available at a cost / required," and picking a cost reveals the amount field. New questions: liquor-license and health-permit photo uploads, event-availability by daypart (separate from your walk-in operating hours), profit-share percentage, deposit amount, and three payment-infrastructure toggles (POS, tap-to-pay, cash drawer). Days Available is now required, ZIP is required, and there is a "Non-negotiable" checkbox next to the fields that can carry one.

The Concept form. "Need Staff" is no longer a text box — it is real rows: pick the role, how many, the experience level, and how it pays (flat / hourly / tipped, and you can pick more than one). "Previous Work" became repeatable rows (name, dates, link) instead of a paragraph. ZIP is now required, Daypart pairs with Days Available, insurance moved onto the profile, and Entry & Ticketing (walk-in / RSVP / ticketed, plus a cap) is finally saved — it used to be collected and thrown away. The old "Venue Must-Haves" section is gone; those needs are now individual fields you can each mark non-negotiable.

The Resource form. It now splits cleanly: Product gets fulfillment (pickup and/or delivery, delivery radius, delivery times, order minimum); Service gets its own availability, travel radius, willing-to-travel, and a service minimum. Payment terms became a real multi-select (COD, deposit, invoice, and so on) with a deposit-amount field. Your street address is a private matching anchor by default — it only shows publicly if you offer pickup — and ZIP is required.

The Worker form. "Preferred Neighborhood" and "Willing to Travel" are replaced by Work Areas: you tap the parts of town you will work on a map. No home address is ever asked for. ZIP and Days Available are required, and the certifications you enter are what staffing reads later — nobody re-asks for them.

Your profile page is now a mirror of your form. Instead of a summary we designed, it shows exactly the fields you filled in, in the order you entered them, with empty ones left out and only the positive answers shown (no wall of "no / none / not available"). Contact info is deliberately not shown — more on that in the next note. And the address rule differs by type on purpose: venue shows its street address, resource shows it only with pickup, concept shows region only, worker shows work areas and never an address.

The negotiation overlay is the new centerpiece. Open a collaboration and hit "Compare Profiles" and you now get every matchable field laid out in a row with a colored tag saying what kind of conversation it needs: Aligned (already covered), Assign (you both have it — pick who provides it, and that choice lands in the agreement), Conflict (you each said something different — meet in the middle), Declared Term (one side stated a price or condition — accept or counter), or Gap (nobody answered). Every venue money field shows up as a Declared Term the concept can counter. A field either side marked non-negotiable gets a red "Non-negotiable" flag on its row.

The agreement, staffing, and going live. Terms are two-key: nothing locks until you both confirm, and changing any agreed term drops it back to unconfirmed and asks you both again. After you agree, you co-write the public listing (title, photo, promo links) while it is still private. Staffing needs everyone to say yes — a worker who applies has said theirs, and both owners must approve before they are in; when an owner wants to invite someone specific, that person is not contacted until the co-owner has also agreed. Publishing is its own separate two-key confirmation on top of terms. And once a crew is attached, changing the date, time, or location asks everyone to re-confirm — while editing the description or photo does not bother anyone.

Two more you named. Events are now One-off or Series, and the badge on the card reads from that — no more "Pop-Up" sitting on a night that runs all summer. And the finder gained a Time of Day filter, worked out from each event's actual hours instead of asking anyone to tag it.

The next note covers the handful of calls we made on your behalf building from the page instead of the room — including one real question waiting for you. Thank you, Miriam. Usually we follow your list of what went wrong; this time we followed your drawing of how it should be, which is a rarer and more generous thing to be handed.

Building straight from the spec meant a stack of decisions where the document pointed a direction but was not in the room to settle the last inch. Here they are plainly.

The one we actually need you for — contact details on profiles. Right now a profile page does not show the person's email or phone; reaching out goes through the request-and-message flow instead. We did this because your spec is firm that a worker should never be screened out before a conversation starts, and showing raw contact info cuts against that — but a venue or a concept may well want its public contact visible on its own page, and that is your call, not ours. So we left it off all four for now rather than guess. Tell us which of venue / concept / worker / resource should show contact openly, and we will turn it on exactly there.

Pay type is demand-side only. The concept or the event sets how a role pays; a worker has no "preferred pay" field and cannot filter gigs by pay. Your spec called this out directly — a pay filter on the worker side would quietly hide gigs they would happily take — so we did not build one.

Claiming an event we added is manual, by design. If our team posted an event from a public source and the real host wants it, they email us, we verify by hand that it is them, they re-post it under their own account, and we delete our copy. We specifically did not build a one-tap "make this mine" — the human check is the security, and an automatic takeover is a door worth leaving shut.

One thing we deliberately did not finish. There is not yet an owner-driven way to re-invite a specific past crew member on a co-owned event — for now, crew on collaborations come in by applying. We stopped short rather than build a version that could contact someone on a single owner's say-so, which your spec forbids. If bringing back a known crew by name matters, it is a clean follow-up to add properly.

We also made sure nothing already entered vanished under the new shapes. Older profiles keep showing what they said — a venue's existing kitchen and availability, a concept's earlier notes and needs, a resource's old details — even as the new, richer fields sit alongside. Nothing was dropped to make room.

And the honest limit: all of this lives on the sandbox, not the live site, exactly as we agreed. Nothing here has touched thelistpdx.com. When you have walked through it and it feels right, we make the move in a single careful step — and not before you say go.

Thank you, Miriam — for writing the blueprint, and for trusting us to build it while you ran the hundred other things a thing like this takes. The room is ready whenever you are.

You took the sandbox for a real spin — seventy-some events added by hand to learn the tool — and came back with the first of your impressions. We grabbed the three sharpest while you keep going.

The cover photo was the big one, and sneakier than it looked. Adding a picture while editing an event quietly failed — your camera-roll photos (the iPhone HEIC format) and the larger shots were being turned away at the door, so the image just "fell off" with nothing to say why. Now any photo from your camera roll is accepted, resized, and saved on the spot — whether you add it on the way in or while editing later. And on the event's page the photo is no longer jammed into a fixed widescreen box that lopped the top and bottom off a tall shot; it shows the whole picture now. (The photos are staying — they were worth getting right.)

The bulk-add tool finally matches the Submit form on Series dates. You noticed the public form had learned to take a pattern — "every other Sunday, June through September" — and spin out all the dates for you, while the back-office tool still made you type each one by hand. Bulk-add has the same little generator now: pick how often, which day, and the span, hit Generate, and every occurrence drops in.

And the Needs Board stopped letting you post into the void. You could push a posting to the board with the staff or resource toggle on but nothing actually chosen — "a little backwards," as you put it. Now the Post button waits until you have picked at least one real position or resource, with a gentle line telling you so.

These were just the first three off the top of your list — send the full sweep whenever it is ready. Thank you, Miriam, for actually living in the thing; that is where the truest notes come from.

This one started with you, Miriam, doing exactly the right thing: going to the live site to check your Batch 10 notes against what was really there — and running straight into error screens when you clicked Admin and Dashboard.

Here is what was actually going on, because it matters for how you read your own notes: it was not you, and it was not the sandbox. The live site had quietly fallen behind the latest build — a couple of pages were asking for information the live version did not have yet, so instead of loading they threw that polite "something went wrong." Your sandbox testing had been the accurate picture the whole time. We brought the live site back into step, and those pages load again.

Rather than just patch it and move on, we did the bigger thing the moment deserved: there is now an automatic watch on both the live site and the sandbox. Every few minutes it logs in like a real person, opens the pages that matter — including the exact Admin and Dashboard screens that broke on you — and checks that the live site is healthy. If anything drifts, it emails us within minutes. The whole reason this one lingered is that nothing was watching; now something always is.

That second part was our call to make on your behalf — you asked for the bug fixed, and we went a step further and built the tripwire so the next one cannot hide. The quiet gap that let the live site drift out of step in the first place is closed too: the step that keeps it in sync used to fail without a sound, and now it fails loudly.

Thank you, Miriam — you found this by trusting what you saw on the screen over what the changelog claimed. That instinct is worth more than any monitor.

Miriam called this one the big kahuna: one long, careful walk through the whole platform before the migration, catching everything that was broken, backwards, or just quietly lying. It was the largest single list she has sent, and it is all cleared. This first note is for the things that were actually broken; a second one follows for the polish.

The one that stung most: you would apply to a gig from your Worker profile, and then — nothing. No record on your side, no status, no way to even tell it had gone through. It turned out to be a black hole at both ends. So now there is a My Applications page that shows every spot you have raised your hand for and where each one stands — Pending, Approved, or not this time — with the ability to withdraw one you have changed your mind about. And on the other side of that handshake, approving someone finally does something visible: one tap fills the spot with their name and tells them they are in. It had been secretly waiting for a second confirmation that the screen never asked for, so a single approve looked like it did nothing at all.

Two profiles under one account stopped stepping on each other, too. You applied to a bartending spot as your Worker, then made a Photography profile and tried to apply to that same event as a vendor — and got told you had already applied. But you had not; your other self had. Each profile now engages on its own, because one person really is several roles, and the platform should know that.

Publishing a collaboration got one front door instead of two. The dashboard already walked you through a proper preview — the real attendee card, the map, a clear "not yet live" banner — but the collaborations screen had its own thinner version where you could publish without ever seeing the assembled event. You asked us to route both through the same real preview, with the publish itself happening there, and that is exactly where it lives now: each partner reviews the true card and confirms from the same place, and it goes live once you both have.

The back office got the same scrutiny. Adding an event through admin could spit raw database gibberish onto the screen, or crash the page outright with a developer error that left you unable to tell whether anything had saved — both fixed, the first by catching the real cause (a stray event type the importer guessed wrong), the second by never letting a hiccup white-screen the page again. Admins can now edit any event after the fact instead of only approving or deleting it, see the full event — every date, the whole description, the image — before approving rather than a clipped summary, and reach bulk-add from the top of the page instead of scrolling to the basement for it.

And Series scheduling finally tells the truth. "Every other Sunday, June 7 through September 13" used to save exactly one of its eight nights. Now you describe the pattern the way you actually think about it — how often, which day, from when to when — and the form shows you the eight dates it is about to create before you commit, and keeps all of them.

The one call here that was ours: approving an applicant now confirms them on the spot, with no second sign-off from the other owner and no re-confirmation from the worker — we read your note as "the act of applying is the commitment," and built it that way. If that is one tap too few, say so and we will add the gate back.

Thank you, Miriam — this was a lot of looking, and the looking is the hard part. You did it; we just followed the list.

The same long walk turned up a stack of smaller things — the kind you only notice by living in the thing. All cleared.

The dashboard greeted some people by the front of their email address — "Welcome gartilox23" — whenever an account had never been asked for a name. It reaches for a real name now: yours if we have it, otherwise the contact name on one of your profiles, and only the email handle as a true last resort. While we were there, the five profile forms stopped treating email, phone, and Instagram as interchangeable — email is required now and the other two are optional, because email is the one address that does not change when a handle gets filtered or a number gets a new phone.

A clutch of small frictions: the quantity box on a need pre-filled a "1" you could not replace, so "2 bartenders" became "12" — it selects on tap now, the way a number field should. Tapping a list card on the finder on your phone just highlighted it and stranded you; it takes you to the event now. Profiles all got real detail pages to land on, including event organizers, who never had one. A back arrow showed up across the inner screens, one that actually retraces your steps instead of dumping you home. The collaboration card got tightened up — same facts, far less scroll. The home page stopped promising "no account needed" for something that now needs one. And the prep-location question swapped its vague "Either" for "Both," with a notes line, since the real case is usually a kitchen in two places at once.

Anywhere you face Accept or Decline, you can now send a short message along with it — a quick reply when you say yes, a courtesy note when you say no — landing in the same thread you already use. Posters arrived, too: admins and hosts can upload a cover photo from their camera roll instead of pasting a link, on the submission form, the back-office entry, and the host's own edit screen — and if a host later claims an event we entered, their image simply takes over.

Two honest notes. The Needs Board button that re-lists a posting now reads "Post to Needs Board" everywhere — which means we walked back the "Repost" wording you picked from our three options last batch; standing next to a panel that said "Posted," "Repost" read as a contradiction, and you flagged it, so "Post" won. And on the routing fixes: organizers now have a profile to route to, but a couple of the spots you mentioned — a host name on an event card, and one collaboration invite that lands on the Needs Board — we could not pin down from here, and left you a note asking for the exact screen.

A few things we did not touch on purpose: the mobile once-over waits for the domain to move, since that is the moment it will actually matter, and the in-person walkthrough is yours to run, not ours. Thank you, Miriam, as always, for the orderly stack of "one more things" — there were a great many this time, and every one of them was real.

Miriam came back having named the thing exactly: there were three "home" screens where there should be two, and a little cluster of bugs that were really just symptoms of that sprawl. So this one was mostly about subtraction — collapsing the logged-in experience down to two clear places.

Account Home is now the umbrella, and its only job is awareness across everything you run. It finally wears the black-and-yellow look from the Choose Your Profile screen you liked: your profiles are cards you tap to step into, and adding a new one is the same tidy 2×2 grid — Venue, Concept, Worker, Resource — instead of the old dashed pills. The new piece is a single notifications feed that spans all your profiles at once, with each note tagged by which profile it belongs to, so tapping one drops you straight into that profile ready to act. Pause Account now sits right next to Delete, where it always should have.

Step into a profile and the Profile Dashboard is now the one place the work happens. A header tells you which profile you are acting as, with a way to switch or climb back up to Account Home, and the Marketplace tools — Browse Directory, Needs Board, Suggested Matches — are folded in as a section right there, instead of drifting off as a separate third screen the way they used to.

Collaborations stopped being one long undifferentiated list. The things that actually want you — new requests, live negotiations, ready-to-publish, still-staffing — sit up top as cards you can act on; the settled ones — published, completed, cancelled — tuck into a quiet reference list underneath. Attention first, archive second.

And the "Preview Event leads to a 404" you flagged turned out to be exactly the symptom you guessed it was: a collaboration’s event was being looked up as though only a Publisher could ever own one, so the page simply could not find it. Teaching it that a venue or concept owns its event too fixed the 404 — and the Edit screen sitting behind it.

Two calls were ours to make, since you were not in the room. Messages still come to you as one person rather than splitting per profile — making a conversation belong to your Concept versus your Worker is a deeper change to how threads are stored, so we have set it aside for its own pass rather than half-do it. And the pause/delete controls for a single profile now live inside that profile rather than on Account Home, which is where the new structure puts "manage just this one." If either sits wrong, say so and we will move it.

Thank you, Miriam — "two homes, not three" was the whole unlock, and it was yours.

The same doc carried the usual stack of sharp little fixes. All cleared.

The Publish Preview used to show a single description box and call it a confirmation. Now it shows the whole assembled card — event name, date, place, entry type, who is collaborating — with a way to edit each, so confirming publish means confirming the event, not one lonely field. And the description you type there now actually lands on the published card; it had been quietly not saving, which was your second note, and you were right.

Resources on the Needs Board finally grew up to match staffing. Staffing had counts, credits, a mark-filled, and an apply-and-approve flow; resources were still dead chips you could only look at. Now you can ask for two of something and watch "1 of 2 filled," credit who is providing it — whether they applied through the board or you found them the old-fashioned way — and resource folks can raise their hand against a category right from the board, for you to approve or pass on. The template was staffing; resources just follow it now.

And cancellation finally follows through. Cancelling used to flip a banner and stop there — the event sat there still public with a working link, and the Needs Board kept cheerfully taking applicants for a night that was not happening. Now it cascades: the event comes down and shows a plain "this event has been cancelled" in its place, the board posting closes so no one new can apply, and the people already booked are told. One action, all the way down.

Thank you, Miriam, as ever, for the steady eye and the orderly stack of "one more things."

Miriam came back with the structural note she had been circling for a while: once a venue and a concept shake hands, the rest of putting on the night was scattered across too many screens, and half of it did not visibly do anything. So we pulled it onto one card and made it move.

It starts back in the negotiation, where the two of you can now say not just which roles you need but how many — two bartenders, one prep cook — and the resources you flag there (florals, a photographer, sound) ride along instead of making you type them twice later.

Then, after both of you confirm, a single card carries the rest: the locked terms up top, a live Needs Board in the middle, and Publish at the bottom — in that order, because that is the order things actually happen. The Needs Board is the part that finally breathes. Each role shows its real count — "Bartender: 1 of 2" — with the names of who has it, and anyone still raising their hand sits right underneath, ready to approve or pass on. Approving someone used to be a shout into the void; now they slide into the role, the count ticks up, and they actually get told. And because this industry staffs through the grapevine as much as any board, you can mark a spot filled by someone you found the old-fashioned way, and put their name on it.

The biggest shift is about publishing. We used to make you finish staffing before the event could go public, which had it exactly backwards — going public is half of how you find the people you still need. So Publish is available the whole time now, sitting in parallel with an open board. If you publish with seats still empty, we ask once, plainly — and the wording of that gentle check is yours, lifted from your note: "Publish this event anyway? Your needs board posting will stay live." Your board stays live and keeps working, and the public page shows the finished face of the event — guests never see the staffing scramble behind it. The old "Mark Ready" button that tried to do all of this from the wrong place, tucked inside an applicant card, is gone.

Two calls here were ours to make on your behalf, since you were not in the room for them. Your note described the three stages but not which screen they should live on — so rather than send you hopping to a separate page, we put the whole thing on the collaboration card itself, where the deal already lives. And for the people you hire the old-fashioned way, off the board, we gave each position a quiet "mark filled" with a spot for their name, so the card can tell the truth about how a night really gets staffed. If either of those sits wrong, say the word and we will move it.

This was the meaty one, and it began — like all of them — as Miriam seeing the shape of the thing before the screens caught up. Thank you, Miriam, for the patience to draw it out.

The same doc carried a handful of smaller fixes, the kind that only surface when you actually live in the thing. We cleared all of them.

The All Events list had a quiet bug Miriam caught by counting: events happening today were buried in the scroll behind ones months out. The list had simply forgotten to put itself in order. It reads soonest-first now, today at the top where it belongs — the calendar had been doing this all along, which is how she knew.

The Submit an Event form asked for Instagram, email, or phone — but it also promised "sign in later to manage your submission," and only email can actually open that door. So a host who left just a phone number was being made a promise we could not keep. Email is the one contact method now, and the promise holds.

Inside negotiations, a "Private Notes" box that never quite knew its job is gone — the per-section notes and the message thread already cover everything it tried to, and its fine print hinted that messages might be public when they never are. And the Needs Board buttons finally speak with one voice. You left us three names to choose from for the button that re-lists a posting — Update, Edit, or Repost — and we went with "Repost to Needs Board," since the action really does push it back out to the board. "Reopen" is gone (it made a posting sound like it had died and come back), and "Post to Needs Board" now reads the same everywhere it appears.

Last, a bit of parity: the recurring and series dates — a weekend run, "every Monday and Tuesday through July" — that already worked on the public form now work when the team adds an event from the back office too. Thank you, Miriam, as always, for the sharp eye and the steady stack of "one more things."

Miriam sent a doc that pointed at the part of The List that had stayed the most hand-wavy: the moment a venue and a concept actually agree to do something together. Until now, "negotiating terms" was a single freeform money box and a lot of good faith. She wanted it to feel like the conversation it really is.

So the negotiation step grew real sections. Date and time. Legal, split into licensing, permits, and insurance — with a checkbox for who is covering each. Equipment, food sourcing, and where the prep happens. The financial agreement, kept as plain words because that part resists tidy boxes. And a Needs section: do you need staff (which roles?) and do you need resources (photography, sound, florals, the rest)?

The quietly clever bit is that the form does not start blank. It reads both profiles and fills itself in. If the venue holds the liquor license and the concept does not, it checks the venue's box and moves on. If both carry insurance, it leaves the question open for the two of them to settle. And if neither side has, say, a sound tech, it drops that straight into the Needs list as a gap to fill. Every guess is editable — it is an assistant leaning over your shoulder, not a rule. To make any of that possible, profiles themselves learned to carry these details, so there was something real to reason about.

When both sides confirm, a genuine event card comes into being — holding all the agreed terms — but it goes precisely nowhere on its own. From there the choice is yours: publish it to the public finder, or post its staffing and resource needs to the board so workers and vendors can find the gig. The system never reaches over and does it for you. When you do post to the board, the staff roles and resource categories you already settled come pre-filled, so you are not typing the same thing twice.

This was the biggest single arc we have built from one of Miriam's docs — she flagged at the outset that the whole reconciliation idea is only as good as the profile forms underneath it, and she was right, so we built those first. Thank you, Miriam, for seeing the shape of the thing before it existed.

Alongside the big negotiation work, the same doc carried a fistful of smaller notes — the kind that come from actually living inside the product. We worked through all of them.

Reaching out to a potential collaborator no longer asks you to invent a title for the conversation before you have even said hello; that field is gone. Messaging now stays open through the whole life of a collaboration instead of going quiet partway through — a deal that is winding down or wrapping up can still talk. The preview screen you see before publishing finally has an Edit button, so a typo spotted at the last second is a quick fix rather than a dead end.

"Residency" became "Series," and the choice between a one-night pop-up and a recurring series is clearer now — picking the shape sets the rhythm for you instead of making you answer the same question twice. Events that The List team adds from public posts wear a small, honest note inviting the real host to email and take the listing over. And reposting an event's needs to the board now asks which positions are still open, rather than assuming every seat came empty.

The last one was Miriam's "for later, lower priority" wish: events can carry a cover photo now. Upload it on the submit form, and it shows up on the event's own page — not crowding the map pins or the calendar, just there when someone comes to look closer.

Every one of these started as a line in her notes. Thank you, Miriam — the sharp eye and the steady stream of "here's one more thing" are exactly what keeps this honest.

Before the site moves onto its real domain, Miriam sent a different kind of note — not bugs this time, but voice. The placeholder marketing copy we had written to fill the early pages could finally step aside for the thing she actually wanted to say.

On the home page, the neat four-box “value proposition” and its generic line are gone. In their place, three plain sentences in her words: people are doing cool things and we are missing it, others have big ideas but cannot make ends meet, and that is where The List comes in. Find, follow, attend — and if you want to build, find your collaborators. We are better together.

The About page gave up its careful scaffolding — the Story, the four little belief cards — for a love letter with teeth. Razor-thin margins and twelve-hour shifts, a milk crate and a cold staff meal eaten out by the trash cans, finding what you love and letting it kill you. It signs off the way the whole project means to live: “by industry, for industry.” The “What’s Coming” and “How It Works” sections went quiet on purpose, held back for launch.

This one is small in code and large in spirit — the platform finding its own register, gritty and warm and unmistakably hers. Thank you, Miriam, for trusting it with your own voice.

Miriam sent a doc that opened with structure, not bugs — the difference between an account (the umbrella that is just you) and a profile (a role you put on). Half the little glitches underneath turned out to be that one idea not yet drawn clearly. She saw it before the symptoms made sense, which is becoming a pattern.

So we drew it. Signing in lands you on your own Account Home now, with your marketplace profiles laid out as doors you choose to walk through — not dropped at random into one of them. Pause and delete grew up too: you can pause or delete a single profile without touching the others, or step the whole account back, each behind a clear "are you sure." Workers finally got a pause of their own — they were the one role that had been left out.

On the back-of-house side, we taught the admin tools to mind their own business. The bulk-add makes events only now (members sign themselves up), and the approval queue holds events and nothing else — venues, concepts, and the rest go live on their own, because curating people one at a time was never the plan. A crossed wire that had private collaborations surfacing in the admin queue is untangled.

The fun one: events that refuse to fit on a single day. A weekend residency, a week-long pop-up, "every Monday and Tuesday through July." The List can hold all three shapes now. The real dates are computed and exact — that is what the map and calendar trust — and a friendly sentence rides alongside ("Mondays & Tuesdays through July"), with the next actual date always shown next to it so the words never have to be taken on faith. We sketched that split together over a cup of coffee’s worth of back-and-forth; it is the kind of small decision that keeps a feature honest.

And the map remembers its lesson from last time — a stray, non-standard date can no longer quietly knock an event off it.

Every piece of this began as a note from Miriam. Thank you, again, for the clarity and for the nerve to keep building the thing.

Miriam sent over a doc with the kind of notes that make this easy: clear, specific, and never bossy about it. We worked through all of it.

The events finder flows the right way now — from today forward, closest dates first. No more scrolling past last spring to find next week. "Featured" means what is actually happening this week, cycling in and out on its own. Each card wears its entry type like a little badge: Ticketed, RSVP Only, or Walk-In, with a filter to match.

There was a proper detective story in here. Miriam noticed that some admin-entered events showed up in the list but quietly vanished from the map and the calendar. The culprit turned out to be a single hopeful run-on date — "05/29/26 5/30/26 5/31/26 every Friday thru Sunday" — which the map read as ancient history and the calendar could not place at all. We taught the app to read dates more forgivingly and to refuse the truly unparseable ones before they cause trouble. The Katsu Sando pop-up is back on the map where it belongs.

Resource profiles can finally say they do both a product and a service, because plenty of them do. And the admin event form stopped asking for ZIP and neighborhood twice — it figures those out from the address now.

Thank you, Miriam. The sharp eyes and the patience are the whole reason this keeps getting better.

Miriam went looking for the events she had bookmarked and could not find the door. She had to wander through the Submit Event form to get there, which is nobody's idea of a good time.

So saving has a front door now: a "Saved" link right in the top nav the moment you sign in, leading straight to your account home with your upcoming saves, your past ones, and the people you follow.

Small fix, but it came from her actually using the thing — which is the best kind of bug report.

Some test data had wandered onto the public map — events with names like "[E2E] Confirm terms" that only ever belonged in our sandbox. Not harmful, just untidy, like finding rehearsal notes taped to opening-night seats.

We taught the public pages and the admin panels to ignore anything that looks like test scaffolding, and tidied up the stray rows. The map shows real Portland again.

For a while The List had two personalities: a lively marketplace for the industry, and a public side that was really just a flyer board. Miriam felt that asymmetry before any of us could name it, and she was right.

Now anyone can have an account. Save an event you want to remember. Follow a chef, a venue, a pop-up whose work you love. Your account is yours first; the marketplace is something you add to it when you are ready, not a gate you have to pass through.

We rebuilt the front door to match. One neutral sign-in for everyone — no passwords to forget, just a one-time link in your inbox. The old "Industry Portal" framing stepped aside so the platform could feel like it is for people first, professionals included.

Miriam had sketched a more elaborate version of all this, with separate doors and a "Patron" label. We talked it through and landed somewhere simpler together. That conversation — her openness to "let me sit with it," then "yes, that makes sense" — is what good collaboration actually feels like.

Long before any of this had a login screen, The List PDX was an idea Miriam had been carrying for about a year and a half — a real hub for Portland’s food and drink world, with the irreverence and punk-rock heart of the scene it’s for. She had built a rough version in Webflow, and one December night she shared it with the simplest possible note: here’s the vision, it’s still rough.

The reply was just as simple — send over the cool stuff and let’s see what we can cook up. A weekend of tinkering later there was a clickable prototype. Her verdict: "borderline concerning if it wasn’t so cool."

In January the real spark hit. Handed the keys to Claude, Miriam watched a working, intuitive form come together in a few minutes — after, in her words, a year and a half "in the oven" doing it the hard way. Mind blown, she said. And then she did the thing that makes all the difference: she did not just hand off her notes, she rolled up her sleeves and learned to build. GitHub, issues, pull requests, deploys — the whole unfamiliar toolbox. There were the inevitable "I think I may have fucked up" moments (she hadn’t — that one was a permissions slip on our end), and she kept going anyway.

By February she was, in her words, "poppin off" — forms live, real data coming in, a way forward she could see for herself. The design arrived in careful drops: the homepage, the user flows, then the marketplace — venues, concepts, and, once she realized the model needed it, a fourth door for the workers who actually make these nights happen.

Spring was the long, patient work of turning a vision into something real: pre-launch punch lists, bug batches, a fifth profile for the people who publish events, and finally waking up the public side so anyone — not just the industry — could find what’s happening and hold onto it.

None of it would exist without Miriam’s eye, her stubbornness in the very best sense, and her generosity — right down to the thank-you wine her "wino peanut gallery" helped pick out. This whole thing is hers. We just get the joy of helping build it.