Team Meeting Log - snuhcs-course/swpp-2026-project-team-09 GitHub Wiki

Agenda: Agree on the Iteration 1 goal, the roadmap, the way of working and the technical setup.

Attendees: 김태현, 안진영, 윤유상, 함재현

1. Iteration 1 goal: a runnable Android prototype in which a student joins a Party for a campus event and finds its members on the map.
2. Roadmap: Iteration 1 finishes most of the core features. Iteration 2 connects the AI features and finishes implementing all features. From Iteration 3, the team focuses on testing, review, improving existing features and expansion, including starting deployment.
3. Way of working: spec, then tickets, then pull requests.
   1. The PM of each iteration writes the spec in .scratch/ with /grill-with-docs, based on the final proposal, the schedule and team discussion.
   2. Each owner splits the spec into tickets with /to-tickets in their own session. One ticket becomes one pull request.
   3. The owner implements a ticket with /implement.
   4. The skill settings are kept in the repository, so that everyone works with the same skills and rules.
4. Servers: the backend is split into main, socket, match and worker servers. The match server has its own database. Redis holds volatile data and reduces load. PostgreSQL holds persistent data.
5. Clients: the mobile app uses Expo (React Native) and the admin web uses Next.js.
6. Map: Kakao Map, because it provides walking routes.
7. Admin: the admin web handles basic management of user data and events, which is inconvenient to do directly in the database. In Iteration 1 it covers creating and editing events.
8. External APIs: Google sign-in, dining, timetable and events are checked first. The shuttle is shown at the stop it is at. Between two stops, it is shown at the stop it left, because the source gives no position in between.
9. Milestones: the first pass of the backend is done by 10-02. The mid-iteration check-in on 10-04 reviews it together with the wireframes and adjusts the tasks.
10. Meetings: a daily standup in the team DM around midnight, a mid-iteration check-in at the end of the first week of each iteration, and an iteration review on its last day.

• Frontend: work starts around 09-30 with provisional login, map and timetable screens. The wireframes matter most, and about a week until 10-04 goes into them. The event-to-party, friend meetup, dining and shuttle screens are built on the wireframes afterwards.
• SNU SSO: access to the SNU SSO login portal seems to be given only to larger institutions.

To settle by the mid-iteration check-in.

1. Deployment timing: the team agreed to start deployment in Iteration 3, but the schedule has no deployment task before Iteration 5.
2. Map switch: the prototype uses Naver Map. Either the whole map moves to Kakao, or the map stays on Naver and only walking routes come from Kakao's REST API. Someone also needs to register the Kakao app and get its key.
3. Socket role: send location data over the socket, or send only a change signal and let the app fetch the data over HTTP, as the prototype does.
4. Worker server: keep it or move its jobs to the main server. This should be decided before the feeds are connected.
5. AI matching: keep matching rule-based in Iteration 1 and add AI in Iteration 2, or not.
6. Admin scope: when user data management is added. Iteration 1 covers events only.

Agenda: Check the progress of the backend and the frontend, and settle how to work on P06 and its scope.

Attendees: 김태현, 안진영, 윤유상, 함재현

1. Way of working: The frontend implements screens with fake data first. Once that is done, it passes its requirements to the backend, which then implements what is needed.
2. Data integration: Only the interfaces are fixed first, and the mock data is written to match them.
3. Merge policy: No separate branch is created for each P. Work is merged straight into main. Squash merge is used, so merging a whole P at once would erase all of its commit history. Merges into main are therefore done per ticket.
4. P06 scope: The scope is reduced to the login screen and the map screen that appears after login, on Android and iOS. Anything else is handled by adding a task when needed.

• Documents: The documents will be worked on and submitted on Thursday. Drafts already exist. The goal is to have the backend roughly done before Thursday.
• Backend progress: P4, P5 and P7 are done, and P8 is planned to start today. Once P8 is done, the backend will be almost complete. After that, the plan is to refine the backend based on the wireframes and implement additional APIs.
  • P4 (about 16 tickets): .github includes CI and a PR template. The frontend PRs that are currently open should also be updated to follow the template. Attaching screenshots under Test results makes it faster to see the progress.
  • P5: researched how to get the shuttle, dining and event data.
  • P7: implemented the feeds based on the P5 research.
    • Haengsha: event information is crawled and then extracted with AI. AI was going to be left out of Iteration 1, but it will be added.
    • Shuttle: for now, it is only possible to see which stop the shuttle is at. The team is asking the university office and the operating company for the data.
    • Dining: the job that collects the menus periodically is implemented.
  • P8 (planned): basic Party features and location sync.
• Frontend progress: The wireframes for all screens are done. Apart from small fixes, no big changes are expected.
• Why the P06 scope was reduced: The original P06 task had pulled in later steps, such as the P9 wireframes and the detailed implementation from P13 onward, and turned into one large task.

1. iOS: the other parts seem to have no problems, but whether only the map module needs to be set up separately is not confirmed.

Agenda: Close Iteration 1 and talk about the direction of Iteration 2.

Attendees: 김태현, 안진영, 윤유상, 함재현

1. Closing Iteration 1: After this meeting, only today's daily standup and this meeting log remain.
2. Next meeting: The Iteration 2 kickoff is on 2026-10-10 at 13:00.

• AI in Iteration 2: Iteration 2 brings in AI, and the team needs criteria to evaluate it. A benchmark would record which model and which prompt gave which score, so that the choices rest on evidence.
• Testing document: The testing plan is written from the start of the iteration, not at its end.
• Server: The servers should be deployed. Checking the app against servers that run locally is getting hard.
• Main feature: The app has many small features and needs one main feature that ties them together.

1. Main feature: What the main feature is. The team thinks it through and prepares to get the TA's feedback once more next week.

Agenda: Agree on the Iteration 2 goal, the roadmap, the way of working and the technical setup.

Attendees: 김태현, 안진영, 윤유상, 함재현

1. Iteration 2 goal: build the AI assistant, strengthen testing, set up CI/CD and run the backend on the Dev server. Until now the servers ran locally for debugging.
2. Meetup retired: the Meetup and the private Party overlapped. The Meetup is removed and its endpoint now makes a private Party, so networking keeps only public and private Parties.
3. AI party matching dropped: it is removed from the scope.
4. Mocks replaced: the features that run on the wireframe mocks are implemented for real. All logic lives in the backend, and the app only sends requests.

• Testing: tests already exist, but they are strengthened in this iteration.
• Why AI party matching was dropped: it blurred the core experience, which is either friends meeting while sharing their locations or AI matching strangers, and the app should be about one of them. The scope was also too wide, and the matching is hard to evaluate.
• Where the logic lives: the team chose between writing the logic in the app and only sending requests to the backend, or the reverse, and decided to keep all logic in the backend.

1. AI backbone: which model and framework the AI assistant is built on.
2. Evaluation: how to evaluate the AI assistant.

Agenda: Check the progress, find a way past the server issues that slow development down, and prepare the midterm presentation.

Attendees: 김태현, 안진영, 윤유상, 함재현

1. AI backbone: the AI assistant runs on Claude Haiku 5.5.
2. Evaluation: how to evaluate the AI assistant is decided after the midterm presentation.
3. Timetable OCR: its accuracy is improved again in the usage fixes (P20).
4. Server and builds: after the midterm presentation, the team tries moving the Dev server to AWS and adding OTA updates, so that a merged feature reaches a phone without a new build.

• Progress: P6, P7 and P13 are implemented, and the AI assistant was confirmed to work.
• Timetable OCR: it fails on a fair number of screenshots.
• Server: the school server blocks connections from outside the campus network, which is the biggest bottleneck in development.
• Builds: every build takes long, so checking a merged feature on a phone is slow. Moving the server to AWS and adding OTA updates came up as the answer.

1. OCR accuracy: how to raise the accuracy of the timetable OCR.
2. Tool-call limit: the AI assistant fails fairly often when it hits the limit on tool calls. How to solve this.

Agenda: Review Iteration 2 and agree on the open decisions.

Attendees: 김태현, 안진영, 윤유상, 함재현

1. Push notifications: Push alarms and notifications are held until Iteration 3.
2. AWS: Moving the servers to AWS is done.

• AI in Iteration 3: After running the experiments with the AI metric, the team needs a plan to raise the Assistant's agentic performance.
• SNU SSO: The team asks the IT center (정보화본부) whether SNU's SSO can be used. If it can, plan features built on it, such as reserving study spaces.

1. STT and autocomplete for the AI chat: Thinking through the user scenarios, neither seems likely to be used. STT is dropped. Autocomplete is checked against its scenarios again at the Iteration 3 kickoff, which decides whether to add it.
2. Technical depth: A user scenario that needs the AI Assistant and shows technical depth.

Agenda: Confirm the tasks Iteration 3 must cover, discuss additional features, and set the team's direction (user scenarios and technical depth).

Attendees: 김태현, 안진영, 윤유상, 함재현

1. Tasks Iteration 3 must cover: the midterm presentation, freezing the AI evaluation criteria, improving the AI chat, the heuristic evaluation (HE), evaluating AI performance, updating the testing document, and the design process and DevOps documentation.
2. Midterm presentation: over the weekend, the team decides what to say on each slide, short of a full script. A review then checks the keywords and anything left out.
3. Freezing the AI evaluation criteria:
   • The criteria go into section 3, AI module testing, of the testing document, and the thresholds are committed to the wiki before the first official measurement.
   • The metrics also cover the direction of the chat improvements and the new features.
4. HE: other teams test our app (to be announced). The team sorts the results by severity and decides what to fix. The fixes themselves are made in Iteration 4.
5. Testing document: two sections are new.
   • 3. AI module testing: the evaluation criteria and the measured results.
   • 4. Acceptance testing: the plan for the UAT in Iteration 4.
6. Design process and DevOps documentation: written so that the project's technical depth is recognized.
7. Usage fixes: if there is time, or a major bug appears, they get a task of their own.
8. Additional features:
   • In (+): OTA updates, location privacy, and autocomplete in the AI chat (depending on the direction).
   • Out for now (−):
     • Timetable OCR: already improved, and low priority.
     • Notifications (push and in-app): they work the same way on the server side and would serve friend requests, Party requests and so on.
     • User data collection and admin site improvements: a required item of Iteration 5.
9. Direction: the basic AI chat built so far keeps improving in performance, and the design process document is written alongside it.
10. Final conclusion: make the user scenarios concrete through the AI Assistant.
    • Add more events and Parties, and check whether the Assistant handles them well as it is.
    • Over the weekend, list what the AI Assistant can do and attach user scenarios to its main features.
    • Implement until the meeting, and fix things after it.
    • Judging performance:
      • Performance is judged by the results of the quests that come out of a scenario.
      • The team tries to draw objective metrics (final results, tool use) even from subjective aspects, including at the midterm presentation.
      • Figures such as token usage are intermediate metrics.

• How user data is collected: companies record events through analytics, event servers and clients, and test by user story and flow. Doing the same would need a separate server.
• User scenarios and technical depth: how to define the user scenarios, whether AI can reach them more efficiently, and where the technical depth lies in that process.
• 윤유상
  1. Quest packages by student type:
     • Freshmen, senior students and exchange students each want different scenarios. Individual quests, such as getting a student ID, finding study spaces or registering a card, are offered as a package.
     • Since the point is asking about what you do not know, it belongs inside the AI Assistant, which tells users what it can do.
     • The AI does not go online. The team prepares the information in advance and serves fixed lines as packages, depending on the request.
     • Questions the Assistant cannot answer are recorded and patched.
     • The Assistant learns abbreviations such as 학관, 공간 and 윗공, through personalization or an evolving agent. Where 함재현's idea centers on profiles, this task centers on geographic information.
  2. Using poster photos:
     • Information is extracted from a photo of a poster the user is interested in, and a quest and a recruitment post are made from it.
     • A Gmail integration pulls in more detailed information.
     • Duplicate events are detected, and recruitment posts for the same event are grouped. Judging well whether two posts are about the same event is the technical depth. The board exists, but it does not group posts.
• 함재현: matching people
  • Looking into the problems freshmen, third- and fourth-year students and exchange students actually face, the core is human interaction.
  • 밥약 (a senior treating a junior to a meal) works, but the relationship often ends after one meeting, the purpose fades, or only the senior pays. It is also hard to know whom to ask.
  • Goal: fix one-off relationships. Users are matched by the similarity of the preferences in their profiles, so that a match is more likely to last from the start.
  • What the AI does:
    • Each match is managed by a shared agent assigned to it. It passes on the junior's questions or suggests icebreakers.
    • Before they meet, it suggests to the senior what the junior is curious about and topics to break the ice.
  • Advantage over just using Claude: matching is based on the users' information, and that information is known in advance and applied automatically. Matching starts within the same department, with strangers as an option.
  • Technical depth: whether matching similarity leads to real satisfaction remains a weakness. A user survey could justify it.
  • What sets it apart: compared with older matching platforms without AI, it has to stand out in the icebreaking and the matching itself.
• 안진영: focusing on one feature
  • It is doubtful whether human interaction would be rated well. It is strong as a user story, but the measure of whether it works is heuristic.
  • As an alternative, the team could focus on one feature, the Gwanjeong Library seat reservation. If the app opens the login page and the user logs in, it can fetch the token and look up the seats.
  • It would likely be done as a script. It is a hard task and so adds technical depth, but the legal issues need to be considered.
• Privacy: some people are sensitive about what information the AI can reach.
  • It is unknown how well the app protects privacy now, and there is reportedly no metric for it.
  • Building technical depth here could let the app serve these people too.

1. Evaluating matching: how to show that similarity leads to real satisfaction.
2. Gwanjeong Library reservation: whether it raises legal issues.
3. Privacy metric: how to measure privacy protection.

Agenda:

Attendees:

1. Topic:

• Topic:

1. Topic:

Agenda:

Attendees:

1. Topic:

• Topic:

1. Topic: