Skip to content
WeSmile

The full picture

What nineteen domains add up to

Grouped by how students use it, not by how the code is organised. Everything here works today; what doesn't is listed at the bottom.

01

Social

The foundation. Things get posted, seen and talked about.

  • Feed and topics

    The campus feed, with topic hubs and six browsing ranges.

    • Six browsing ranges, nearest outward: campus, school, district, city, province, everywhere — it decides how far *you* look, not who a given post is shown to

    • Topic hubs sort by newest or hottest; hot posts get their own stream

    • Likes, saves, shares and threaded comments; list counts are batched into a fixed number of queries per page

    • Image grids with full-screen preview; images upload straight to object storage, never through the app server

  • Anonymous tree hole

    Anonymous to other users, not to the system.

    • Authors appear as a persona they can reshuffle; the client never receives a real author id, which is why tree-hole comments have no "report this person" path

    • A "hug" replaces the like — it fits the register of the place

    • Anonymous comments; the body field differs from a normal post, and the differences across the four commentable types are collapsed into one adapter table

    • Content still passes safety screening, still gets reported and removed, and penalties land on the real account

  • Direct messages

    Live, and defensive by default.

    • WebSocket delivery, falling back to polling when the socket can't connect, so the list is never empty for the wrong reason

    • Unanswered quota: until they reply, you get three messages

    • Three privacy levels: open, three-until-reply, or closed

    • Blocking and recall; a marketplace listing opens a chat with the seller in one tap

  • Search and discovery

    Three target types, searched separately; a discovery page for "what's happening today".

    • Search splits into posts, people and events

    • Trending queries are computed server-side, not hardcoded

    • The discovery page carries the carousel, the shortcut grid, a daily poem, hot topics and hot posts

02

Campus life

The handful of high-frequency offline things, moved in.

  • Events

    One event can have several sessions; sign-ups attach to a session.

    • Hosts set a location (map picker), a time, sessions and a capacity

    • The roster is readable; "hosting" and "attending" are separate views

    • A timeline tracks progress, and comments use the shared component

    • Events go through the same review and unpublish flow as posts

  • Marketplace

    Second-hand goods on campus; the transaction itself happens in person.

    • Listings carry images and a price and are searchable

    • One tap to message the seller — no friend request first

    • Comments for the follow-up questions, shared with the feed

    • Unpublish and soft-delete with restore

  • Course reviews

    Grading and teaching rated separately.

    • Find courses by teacher, faculty, campus or school

    • Two scores: how they grade, and how they teach

    • Reviews are anonymous — only the score and the text are shown

    • Trending search terms are maintained server-side

  • Weekly match

    Questionnaire, human pairing, contacts exchanged. Deliberately not an algorithm.

    • The sign-up form is edited visually in the console: question types, options and order all change, and edits attach to question ids so existing answers never shift

    • An operator opens two questionnaires side by side and confirms the pair — or unpairs and sends both back to the pool

    • Matched pairs can see each other's contact details

    • Why no algorithm: one round a week over a small pool, human pairing produces better results and, more importantly, explainable ones

03

Identity and trust

This is what decides whether you dare open any of the above.

  • Student verification

    Three routes; each school picks which ones it opens.

    • Email: a code to the school address, resolved on the spot

    • Student card photo: an AI pre-screen first, anything doubtful goes to a human — who sees the reason the AI gave

    • Campus quiz: each school's own question bank, single and multiple choice, with a configurable pass mark (leave it blank to require a perfect score)

    • The rejection reason is required free text and is forwarded verbatim; resubmission opens at the same time

    • If a school has fewer live questions than one quiz needs, that route reports itself unavailable rather than padding with another school's questions

  • Capabilities and penalties

    "What can I do right now" is one server call, not client-side reasoning.

    • Five capability names: post, comment, message, join, match

    • A full ban shows a site-wide banner with the expiry; when waiting it out is the only option, no button is offered — false hope is worse than none

    • Clients never derive the rules themselves, because derived rules fork across four surfaces

  • Clubs and unions

    A club is an entity, not a tag.

    • Clubs get a page and a cover; a member's title travels with their posts — the author line reads "club · role", no profile visit needed

    • Students browse clubs and apply to join; applications are reviewed, and "clubs I'm in" is on their profile

    • Applications are reviewed by a club admin in the console — they manage exactly the one club they were granted, and other clubs at the same school don't exist as far as they're concerned; campus and platform admins can remove a member as a backstop

    • Membership and club title coexist: club admins review title applications and supporting material in the console; approval makes the applicant a member automatically, but not the other way round

    • Good for handing recruitment and event publishing back to the clubs themselves

  • Schools and campuses

    One deployment can carry several schools.

    • School / faculty / campus / place, four levels — and geography hangs off the campus, not the school, because one school's two campuses are routinely in two different districts

    • The school field is a product of verification and users can't edit it; the campus they choose themselves

    • The three nearest browsing ranges resolve directly against this structure

04

Operations and governance

The console is for operators, not for developers.

  • Reports and review

    Reports have structure; resolutions leave a trace.

    • Four target types (user, post, comment, message) × five reasons, with up to six pieces of evidence (image or video)

    • One queue handles eight content types; posts, listings and events can also be unpublished

    • Deletes are always soft — you can look back, and you can restore

    • If someone already resolved an item, it says so instead of letting two people judge it twice

  • Homepage configuration

    Everything is configurable, and misconfiguration won't save.

    • Carousels belong to a named slot, and the slot list is an enum — so you can't publish into a position nothing renders

    • Placements, the daily poem, the shortcut grid, homepage tabs, topics and broadcast notices are all managed here

    • Six targeting levels: everywhere / a province / a city / one school / several schools / one campus. The same carousel can run for one school only, or one campus only

    • A campus admin can only target their own school and campuses — the wider levels never appear for them, rather than being refused after they pick one

    • Deep links are validated against the mini program's page registry; a wrong path is caught at submit time

    • New entries start unpublished, with a "publish now" switch on the form

  • Admins and permissions

    Effective rights = what the role allows ∩ what the scope allows.

    • Five roles: super admin, operator, moderator, campus admin, club admin

    • A campus admin can create operators and moderators for their own school — but not peers, and not accounts at another school

    • Out-of-scope access returns "not found" rather than "forbidden", so nothing leaks by probing

    • Suspending or deleting an admin drops their sessions immediately; their history stays attributed

  • Points and orders

    In-app points, on an order system that was not written only for points.

    • Earned by checking in, with streaks paying more

    • WeChat Pay top-ups: JSAPI in the mini program and Native QR payment on the web; tiers are configured in the console

    • Every movement is itemised; orders filter by type and status, and can be refunded

    • Orders are generic, not "top-up orders": the kind of purchase is a field, so memberships, gifts or paid features later need no second table — hard-coding "payment" as "points tier" is a debt you repay

  • Metrics and events

    A dashboard and behavioural logging.

    • The dashboard narrows by scope: a campus admin sees their own school's numbers

    • Launch events and behavioural logging are their own domain

    • The AI provider is swappable — it speaks the OpenAI-compatible protocol, so switching means a URL, a key and a model name

What still needs work

Better written down than buried. If one of these blocks you, you should know now.

  • A small number of personalised endpoints still require a session: recent searches are unavailable to visitors, and the web app hides that block rather than erroring.

  • Front-end tests still lean toward rules and pure functions; component rendering, browser integration and cross-surface payment regression coverage need more work.