Including what still needs work

Yes, but the first release has to be smaller. Open the feed, the tree hole and events; enable email verification only. The real bottleneck isn't development, it's moderation — and its cost isn't volume, it's response time, so you need at least two people who can rotate.

Development isn't the critical path. Mini-program release review and, when top-ups are enabled, merchant verification both need lead time. The rest of the time goes into configuring the school, writing quiz questions, seeding content and staffing moderation.

It's self-hosted. The hard costs are a server for MySQL and Redis, an object storage bucket and a mini-program account. That mini-program account also supports web QR sign-in; top-ups need a merchant account. Bandwidth is mostly images, and images upload straight to storage rather than through the app server.

If you're opening the tree hole or direct messages, effectively yes. Verification isn't about keeping people out; it's what makes a penalty mean anything. Where a banned account is replaced in five minutes, every moderation tool is decoration. Email-only verification is the cheapest place to start.

It would, which is why anonymity here means anonymous to other users, not to the system. Content still passes safety screening, still gets reported and taken down, and penalties still land on the real account. Users only ever see a persona.

Three layers. A default quota: three messages until they reply. A privacy setting the user controls: open, three-until-reply, or closed. Then blocking and reporting — direct messages are one of the four reportable target types.

One round a week over a small pool: an algorithm's results are no better and much harder to explain. An operator reads two questionnaires, confirms the pair, and can say why when someone asks.

A campus is a first-class entity and geography hangs off it rather than off the school — two campuses in two districts is normal. "My campus" and "my district" are two of the browsing ranges. Users choose their campus; they can't change their school, because the school comes from verification.

Yes. Each gets its own campus admins, quiz bank, pass mark and content boundary. Cross-school access returns "not found" rather than "forbidden", so an admin can neither see nor deduce what another school has.

Yes. A club admin manages exactly the one club they were granted; other clubs at the same school don't exist for them. Campus admins can also create their own operators and moderators, but can't create peers or accounts at another school.

You do — in your own database and your own storage bucket. It's self-hosted, and there's no central service anything has to report back to.

It can complete the core journey independently: Native QR top-ups and SMS phone binding both work on the web. It cannot replace WeChat-only conveniences such as subscription-message consent and one-tap WeChat phone binding.

Yes. After choosing a tier, the web app creates a WeChat Native payment QR code and refreshes the balance and history when payment succeeds. The mini program uses JSAPI; both paths share the same orders, callback and reconciliation.

Yes. The web app binds by SMS verification and then continues student verification. The mini program also offers one-tap WeChat phone binding, and both methods update the same account.

The server is sliced by business domain: one domain is one directory containing the same fixed sub-packages — controller, service, repository, entity, request and response. Adding a module means adding a directory, not scattering files across five flat packages.

Public content, carousels and topics are available. Recent searches remain a signed-in personalisation, so visitors simply do not see that small block. Publishing, reactions and direct messages still require a session.

The server covers core paths, known traps, entity-to-schema consistency, migrations and hand-written SQL against real MySQL. The web app, console and mini program also test rules and business logic, but component rendering, browser integration and cross-surface payment regression coverage remain thin. The front end is still the next testing priority.