Connect Yonsei Session

---
name: connect-yonsei-session
description: Connect once to the official Yonsei Portal in a persistent managed browser profile, reuse supported school SSO sessions, and resume after expiry without collecting credentials. Use when a student says 로그인, 포털 연결, 로그인 유지, 세션 만료, or asks to use an authenticated Yonsei service such as academic information, LearnUs, attendance, shuttle, space, library, counseling, student ID, or certificates.
---

# Connect Yonsei Session

Use the persistent Yonsei-managed Chrome, Edge, or Chromium profile. Keep the
official browser session as the shared login layer for later Yonsei tasks.

## Preferred command path

Call `yonsei_bridge_connect`. It opens or reuses the managed browser and
reports the exact official login page. Let the student finish authentication in
that page, then call it again before resuming the original request.

## Workflow

1. Reuse the Yonsei-managed browser profile. On a host that explicitly exposes
   an already open official tab to the bridge, it may attach to that tab;
   otherwise it opens its own persistent profile at:

   `https://portal.yonsei.ac.kr/ui/index.html`

2. Check the visible page only. Do not inspect cookies, browser storage, saved
   passwords, network credentials, or profile files.
   When an HTML snapshot was supplied instead of a live browser, classify it
   without extracting credentials:

   ```bash
   python3 "$SKILL_DIR/scripts/classify_login_page.py" \
     --html "<snapshot>" \
     --success-marker "<visible authorized service label>"
   ```

3. Open Portal first, then follow its visible **학사정보시스템/Underwood** link
   when the requested task is in Underwood. Let the official redirect perform
   SSO in that same profile; do not reconstruct the POST or copy session data.
4. If the requested service opens without an ID, password, MFA, or portal-login
   screen, continue without interrupting the student.
5. If authentication is required, leave that exact official tab open and ask
   the student once to finish login there. Never ask for a password or OTP in
   chat and never move those values into a terminal command.
6. After the student finishes, resume in the same browser profile and open the
   requested service again. Treat visible service content, not a portal HTTP
   response or a stored-cookie claim, as proof that login worked.
7. Keep using the same managed browser profile for academic information,
   LearnUs, attendance, shuttle, library, counseling, student ID, and
   certificates. Do not start a separate headless browser for each service.
8. If a downstream service has a separate institutional login, such as the
   current space-reservation service, group the
   remaining login screens together, let the student complete each official
   screen once, then continue the original task.
9. On expiry, record the requested service and last confirmed read-only step,
   return to the official login screen in the same profile, ask for one login
   handoff, and resume from that safe step. Never repeat an uncertain
   reservation, application, issuance, or payment action after
   reauthentication.

Read `references/browser-session.md` when deciding whether a page is connected,
expired, or service-specific.

## Result

Report only:

- connected service or the exact official login screen awaiting the student
- whether the browser profile can be reused for the current task
- any service that still requires separate authentication
- the original task that will resume next

Do not expose identifiers, credentials, cookies, or authentication parameters.